SMTP DMARC Policy: Enforce SPF and DKIM Alignment (2026)

DMARC doesn’t actually enforce anything itself; it’s a policy that tells receiving mail servers what to do with messages that fail SPF and DKIM checks and alignment.

Let’s see DMARC in action. Imagine a malicious actor, "EvilCorp," sending emails that spoof your domain, yourcompany.com.

# An email from EvilCorp, spoofing your domain

MAIL FROM: <badguy@yourcompany.com>
RCPT TO: <victim@theircompany.com>
DATA
Subject: Urgent Account Verification Required!

Dear Valued Customer,

Your account has been flagged for suspicious activity. Please click the link below to verify your details immediately:
[malicious-link.ru]

Sincerely,
YourCompany Security Team

Now, let’s say your company has a DMARC record published.

First, SPF (Sender Policy Framework). Your SPF record, published in DNS for yourcompany.com, might look like this:

yourcompany.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all"

This record states that only Google’s mail servers (via _spf.google.com) and Microsoft’s (via spf.protection.outlook.com) are authorized to send email claiming to be from yourcompany.com. The -all means any other server is not authorized.

Second, DKIM (DomainKeys Identified Mail). When a legitimate email is sent from your domain, your mail server signs it with a private key. The corresponding public key is published in DNS:

selector._domainkey.yourcompany.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

The receiving server checks the signature. If it’s valid and the d= tag in the DKIM signature matches yourcompany.com, SPF and DKIM pass.

But DMARC adds alignment. It checks if the "From" header domain (what the user sees) matches the domain verified by SPF or DKIM.

Let’s say EvilCorp’s email doesn’t pass SPF for yourcompany.com (because they aren’t using Google or Microsoft’s servers) and it doesn’t have a valid DKIM signature for yourcompany.com.

Your DMARC record, also published in DNS, tells receivers what to do:

_dmarc.yourcompany.com.  3600  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourcompany.com; ruf=mailto:dmarc-forensics@yourcompany.com; adkim=s; aspf=s"

Here’s what that means:

v=DMARC1: Specifies DMARC version 1.
p=reject: This is the policy. reject tells receivers to discard emails that fail DMARC checks (i.e., fail SPF/DKIM and alignment). Other options are quarantine (send to spam) and none (monitor only).
rua=mailto:dmarc-reports@yourcompany.com: This is for aggregate reports. Receiving servers will periodically send you summaries of mail traffic, including DMARC results.
ruf=mailto:dmarc-forensics@yourcompany.com: This is for forensic (message-specific) reports. These are individual reports sent when a message fails DMARC, useful for detailed investigation.
adkim=s: This enforces strict DKIM alignment. The domain in the d= tag of the DKIM signature must exactly match the domain in the "From" header. r (relaxed) would allow subdomains.
aspf=s: This enforces strict SPF alignment. The domain used in the SPF check (the MAIL FROM or Return-Path domain) must exactly match the domain in the "From" header. r (relaxed) would allow subdomains.

Because EvilCorp’s email fails both SPF and DKIM for yourcompany.com, and the "From" header domain is yourcompany.com, the DMARC check fails. With p=reject, the receiving server will simply delete the email, preventing it from reaching the victim.

The most surprising true thing about DMARC is that it doesn’t check the actual sender of the email. It checks the alignment between the "From" header domain (what the user sees) and the domains authenticated by SPF and DKIM. This is why a perfectly legitimate email could fail DMARC if its Return-Path or DKIM d= tag doesn’t align with the visible "From" address.

The most common pitfall with DMARC is misconfiguring SPF or DKIM, or having legitimate services (like email marketing platforms or CRM systems) that send mail on your behalf but aren’t included in your SPF record or aren’t DKIM-signing with your domain. This can lead to legitimate emails being rejected if your DMARC policy is set to reject or quarantine too early.

The next concept you’ll grapple with is understanding and acting upon the DMARC aggregate (RUA) and forensic (RUF) reports, which are essential for identifying legitimate mail sources that need to be brought into alignment before enforcing a reject policy.