DMARC, SPF, and DKIM: The Email Security Trifecta Your Domain Needs

In our recent scan of 50 companies, 100% of those that received a Grade F were missing DMARC records entirely. Not a single one had configured this free, standard protection against email spoofing. This finding was so consistent that it became the single most reliable predictor of an organization's overall security posture: if you do not have DMARC, you probably do not have much else either.

Email authentication is not optional. Domain spoofing is the foundation of business email compromise (BEC), phishing campaigns, and brand impersonation attacks. The FBI's IC3 reported over $2.9 billion in BEC losses in 2023 alone. Three DNS records -- SPF, DKIM, and DMARC -- working together can prevent the vast majority of these attacks. They are free to implement, take less than an afternoon to configure, and require no software installation.

This guide walks through what each protocol does, how to set them up correctly, common mistakes to avoid, and how to test your configuration.

Why All Three Are Needed Together

SPF, DKIM, and DMARC are complementary protocols that each address a different aspect of email authentication. None of them is sufficient alone:

• SPF (Sender Policy Framework) verifies that the sending mail server is authorized to send email for your domain. It checks the envelope sender (the "mail from" address used in the SMTP transaction).
• DKIM (DomainKeys Identified Mail) adds a cryptographic signature to email headers, proving that the message was sent by someone with access to your private key and that the message was not modified in transit.
• DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together by telling receiving servers what to do when authentication fails, and it checks that the domain in the visible "From" header aligns with the SPF or DKIM domain.

Without DMARC, SPF and DKIM operate independently with no enforcement policy. A receiving server might check SPF and DKIM, but if both fail, the default action is usually to deliver the email anyway (possibly with a spam score adjustment). DMARC changes this by providing an explicit policy: reject the email, quarantine it, or at minimum report it.

The alignment check is critical. An attacker can send email using their own server (passing their own SPF) and their own DKIM key, but set the visible "From" header to your domain. Without DMARC's alignment requirement, this email passes both SPF and DKIM -- just not for your domain. DMARC catches this by requiring that the SPF or DKIM domain matches the visible "From" domain.

Step 1: Set Up SPF

SPF is a DNS TXT record on your domain that lists all servers authorized to send email on your behalf.

Basic SPF Record

yourdomain.com TXT "v=spf1 include:_spf.google.com include:sendgrid.net -all"

Breaking this down:

• v=spf1 -- identifies this as an SPF record
• include:_spf.google.com -- authorizes Google Workspace servers to send email for your domain
• include:sendgrid.net -- authorizes SendGrid (or whatever transactional email provider you use)
• -all -- hard fail: reject email from any server not listed above

Common SPF Mistakes

Too many DNS lookups. The SPF specification limits records to 10 DNS lookups. Each include:, a:, mx:, and redirect: mechanism counts as a lookup, and nested includes count against your total. Organizations using multiple SaaS tools (marketing email, transactional email, CRM, help desk) routinely exceed this limit. When the limit is exceeded, SPF fails entirely -- meaning no email passes SPF authentication.

Check your lookup count:

# Use mxtoolbox.com SPF lookup, or:
dig TXT yourdomain.com +short | grep spf

If you are over 10 lookups, consolidate by using IP ranges (ip4:) instead of includes, or use an SPF flattening service.

Using ~all (soft fail) instead of -all (hard fail). Soft fail tells receivers "this might not be legitimate, but do not reject it." This provides minimal protection. Use -all once you have confirmed all legitimate senders are included in your SPF record.

Forgetting to include all sending sources. Audit every service that sends email using your domain: marketing platforms, transactional email, help desk, CRM, internal applications, and automated systems. A single missing source will cause legitimate email to fail SPF.

Step 2: Set Up DKIM

DKIM requires generating a public/private key pair. The public key is published as a DNS record; the private key is configured on your mail server or email provider.

Generating DKIM Keys

Most email providers generate DKIM keys for you. For Google Workspace, Postmark, SendGrid, and other hosted providers, follow their documentation to generate the key and they will provide the DNS record to publish.

For self-hosted mail servers, generate a key pair with OpenSSL:

# Generate a 2048-bit RSA key pair:
openssl genrsa -out dkim_private.pem 2048
openssl rsa -in dkim_private.pem -pubout -out dkim_public.pem

# Extract the public key for DNS (remove headers and newlines):
grep -v '^-' dkim_public.pem | tr -d '\n'

Publishing the DKIM DNS Record

selector._domainkey.yourdomain.com TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqh..."

The selector is a name you choose (like google or s1) that identifies which key to use. You can have multiple DKIM selectors for different sending services.

Common DKIM Mistakes

• Using 1024-bit keys. While still technically valid, 1024-bit RSA keys are considered weak. Use 2048-bit keys.
• Not rotating keys. DKIM keys should be rotated annually. Old selectors should be removed from DNS after a transition period.
• DNS record too long. A 2048-bit key produces a public key string that exceeds the 255-character limit for a single DNS TXT record string. Split it into multiple strings: "v=DKIM1; k=rsa; p=MIIBIjAN..." "...rest of key..."

Step 3: Set Up DMARC

DMARC is the enforcement layer. It tells receiving servers what to do when SPF or DKIM fails and sends you reports about authentication results.

DMARC Policy Progression

Deploy DMARC in stages to avoid disrupting legitimate email:

Stage 1: Monitor (p=none)

_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1"

This tells receivers to send aggregate reports (rua) and forensic reports (ruf) to your email addresses but take no action on failing emails. Run in this mode for 2-4 weeks and review the reports to identify all legitimate sending sources.

Stage 2: Quarantine (p=quarantine)

_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.com"

Start quarantining failing emails. The pct=25 directive applies the policy to only 25% of failing messages, letting you gradually increase coverage. Raise to 50%, then 75%, then 100% over several weeks as you confirm no legitimate email is affected.

Stage 3: Reject (p=reject)

_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; adkim=s; aspf=s"

Full enforcement. Emails that fail DMARC alignment are rejected outright. The adkim=s and aspf=s directives require strict alignment (exact domain match, not just organizational domain), providing the strongest protection.

Common DMARC Mistakes

• Staying on p=none forever. This is the most common mistake we see. Organizations deploy DMARC in monitoring mode, never review the reports, and never progress to enforcement. p=none provides zero protection -- it only generates reports. Without enforcement, attackers can still spoof your domain with impunity.
• Not processing DMARC reports. Aggregate reports are XML files that are difficult to read manually. Use a DMARC report processing service like dmarcian.com, Valimail, or Postmark's free DMARC monitoring tool to parse and visualize your reports.
• Missing the subdomain policy. DMARC applies to the exact domain in the record. Subdomains without their own DMARC record inherit the parent policy. If you want different policies for subdomains, add sp=reject to your parent domain DMARC record.

Testing Your Configuration

After deploying all three records, verify them with these free tools:

MXToolbox

# Check SPF:
https://mxtoolbox.com/spf.aspx

# Check DKIM (need to know your selector):
https://mxtoolbox.com/dkim.aspx

# Check DMARC:
https://mxtoolbox.com/dmarc.aspx

Command-Line Verification

# Check SPF record:
dig TXT yourdomain.com +short | grep spf

# Check DKIM record (replace 'google' with your selector):
dig TXT google._domainkey.yourdomain.com +short

# Check DMARC record:
dig TXT _dmarc.yourdomain.com +short

Send a Test Email

Send an email to check-auth@verifier.port25.com (a free service by Port25). You will receive an automated reply showing whether your email passed SPF, DKIM, and DMARC checks. Google's Gmail also shows authentication results -- click the three dots on any received email and select "Show original" to see SPF, DKIM, and DMARC pass/fail status.

Why This Matters: The Data

In our scan of 50 companies, the correlation between missing DMARC and overall security posture was stark:

• 100% of Grade F companies had no DMARC record at all
• 75% of Grade C companies had DMARC set to p=none (monitoring only, no enforcement)
• Every company that scored a B or higher had DMARC set to at least p=quarantine

DMARC configuration is a reliable proxy for security maturity because it requires understanding your email infrastructure, auditing all sending sources, and progressively tightening policy -- the same systematic approach that characterizes good security programs in general.

An attacker performing reconnaissance on your domain can check your DMARC record in seconds. If it is missing, they know two things: (1) they can spoof your domain for phishing, and (2) your security program is likely immature, making you a softer target for other attacks.