DMARC Concepts¶

If you're new to email authentication, the terminology can be overwhelming fast. DMARC, SPF, DKIM, alignment, policies, forensic reports — it's a lot of acronyms for what is, at its core, a straightforward problem.

This page explains the key concepts in plain English. You don't need to memorize all of this before using MonitorDMARC, but having a working understanding of how these pieces fit together will make your reports much easier to interpret.

The Core Problem DMARC Solves¶

Email was designed in a more trusting era. The original protocol has no built-in way to verify that an email actually came from who it claims to be from. Anyone can send an email that says it's from billing@yourcompany.com — and without email authentication in place, there's nothing stopping them.

This is how phishing and email spoofing work. Attackers send emails pretending to be your company, your bank, or a service you use — and recipients have no easy way to tell the difference.

DMARC, combined with SPF and DKIM, gives ISPs a way to verify that an email claiming to be from your domain actually came from a server you authorized. If it didn't, your DMARC policy tells them what to do with it: let it through, send it to spam, or reject it outright.

SPF — Sender Policy Framework¶

What it is: A DNS record that lists the mail servers authorized to send email on behalf of your domain.

How it works: When an email arrives, the receiving mail server checks the sending server's IP address against your SPF record in DNS. If the IP is on your approved list, SPF passes. If it's not, SPF fails.

What an SPF record looks like:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Breaking that down:

v=spf1 — This is an SPF record (version 1, the only version)
include:_spf.google.com — Google's mail servers are authorized to send for this domain
include:sendgrid.net — SendGrid's servers are also authorized
~all — Any server not listed should be treated as a soft fail (suspicious, but not outright rejected)

Common all modifiers:

Modifier	Meaning
`-all`	Hard fail — reject email from unlisted servers
`~all`	Soft fail — mark as suspicious but deliver
`?all`	Neutral — no policy on unlisted servers
`+all`	Pass everything — effectively disables SPF (don't use this)

SPF's limitation: SPF only checks the envelope sender — the technical "from" address used during the SMTP handshake. It does not check the "From" address that appears in your email client. This is where DKIM and DMARC alignment come in.

SPF Flattening: SPF records have a lookup limit of 10 DNS lookups. If your record has too many include statements, it can exceed this limit and start failing. SPF flattening is the process of consolidating your SPF record to stay under the limit. MonitorDMARC will alert you if your SPF record is approaching or exceeding this limit.

DKIM — DomainKeys Identified Mail¶

What it is: A method for cryptographically signing outgoing emails so the recipient can verify they haven't been tampered with and that they genuinely originated from your domain.

How it works: Your email server signs outgoing messages with a private key. The corresponding public key is published in your DNS. When a receiving server gets the email, it retrieves your public key from DNS and uses it to verify the signature. If the signature checks out, DKIM passes.

What a DKIM DNS record looks like:

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

The long string at the end (p=MIGfMA0GCSq...) is your public key.

The "selector" part: You can have multiple DKIM keys for the same domain, each identified by a selector name. This is common when you use multiple email services — Google Workspace might use selector google, while SendGrid uses s1. Each service gives you a different DKIM record to publish.

Why DKIM matters beyond SPF: Unlike SPF, DKIM travels with the email itself (as a header). This means it survives email forwarding — SPF often breaks when an email is forwarded because the forwarding server isn't on the original sender's SPF list. DKIM remains intact as long as the email content isn't modified.

DMARC — Domain-based Message Authentication, Reporting, and Conformance¶

What it is: The layer that ties SPF and DKIM together and tells receiving mail servers what to do when authentication fails.

What it does:

Requires that at least one of SPF or DKIM passes and aligns with the domain in the "From" header (more on alignment below)
Tells receiving servers what to do with email that fails: deliver it, quarantine it, or reject it
Instructs receiving servers to send you reports about what they're seeing

What a DMARC record looks like:

v=DMARC1; p=quarantine; rua=mailto:rua@app.monitordmarc.com; ruf=mailto:ruf@app.monitordmarc.com; pct=100

Breaking that down:

Tag	Value	Meaning
`v`	`DMARC1`	This is a DMARC record
`p`	`quarantine`	The policy — what to do with failing email
`rua`	`mailto:rua@app.monitordmarc.com`	Where to send aggregate reports
`ruf`	`mailto:ruf@app.monitordmarc.com`	Where to send forensic reports
`pct`	`100`	Apply the policy to 100% of failing email

DMARC policies:

Policy	What it means
`p=none`	Monitor only — don't do anything with failing email. Useful when you're just getting started and want to understand your email traffic before enforcing anything.
`p=quarantine`	Send failing email to the spam/junk folder
`p=reject`	Block failing email outright — it never reaches the recipient

Most organizations start at p=none to gather data, then move to quarantine, then eventually reject once they're confident all legitimate email is passing authentication.

Important: Moving too quickly to p=reject without understanding your email traffic first is how you accidentally block legitimate email. Use your MonitorDMARC reports to understand everything that's sending on your behalf before tightening your policy.

DMARC Alignment¶

This is the concept that confuses people most often, so it's worth spending a moment on.

DMARC doesn't just require that SPF or DKIM pass — it requires that they pass in alignment with the domain in the "From" header. This is the address your recipients actually see.

Why alignment matters: Without it, an attacker could set up a legitimate domain they control, pass SPF and DKIM for that domain, but put your domain in the "From" header. The authentication would technically pass, but the email would still be spoofed.

SPF Alignment: The domain used in the envelope sender (the technical SMTP "from" address) must match the domain in the "From" header.

DKIM Alignment: The domain in the DKIM signature (d= tag) must match the domain in the "From" header.

Strict vs. Relaxed Alignment:

Mode	Behavior
Relaxed (default)	Subdomains are allowed. `mail.yourdomain.com` aligns with `yourdomain.com`
Strict	Exact match required. `mail.yourdomain.com` does NOT align with `yourdomain.com`

Relaxed alignment is the default and works for most organizations. You'd specify strict alignment in your DMARC record with aspf=s (for SPF) or adkim=s (for DKIM) if you need it.

RUA Reports — Aggregate Reports¶

What they are: Daily summary reports sent by ISPs to the address specified in your DMARC record's rua tag.

Who sends them: Major ISPs including Google, Microsoft, Yahoo, Apple, and many others. Each sender sends one report per day per domain they processed email for.

What they contain:

The reporting organization (e.g., Google, Microsoft)
The date range covered
Your published DMARC policy
A breakdown of email sources: IP addresses, volume, and whether SPF and DKIM passed or failed for each source

What they look like in the raw: Compressed XML files. Here's a tiny excerpt to illustrate why they're unpleasant to read manually:

<record>
  <row>
    <source_ip>209.85.220.41</source_ip>
    <count>847</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
</record>

That's one source IP sending 847 emails that passed both DKIM and SPF. Imagine reading hundreds of these records across dozens of reports every day. MonitorDMARC handles all of that parsing for you.

Frequency: Once per day per reporting organization. Don't expect real-time data — aggregate reports are intentionally delayed by design.

RUF Reports — Forensic Reports¶

What they are: Individual failure reports sent when a specific email fails DMARC authentication. They're sent to the address specified in your DMARC record's ruf tag.

Who sends them: Fewer ISPs than RUA. Notably, Google does not send RUF reports. Microsoft, Yahoo, and some others do. The amount of RUF data you receive will vary significantly depending on where your recipients' email is hosted.

What they contain: More detail than RUA reports — information about the specific message that failed, including headers and authentication results. Some RUF reports include a redacted or full copy of the message body depending on the sender's privacy settings.

How to use them: RUF reports are most useful for diagnosing specific failures. If your aggregate reports show SPF failures from a particular IP address, a corresponding RUF report can show you details about the actual messages involved.

A note on privacy: Because RUF reports can contain email content and recipient information, some organizations choose not to collect them by simply omitting the ruf tag from their DMARC record. This is a legitimate choice, particularly for organizations with strict data handling requirements.

BIMI — Brand Indicators for Message Identification¶

What it is: An emerging standard that lets you display your brand logo in the email client next to your messages — that little icon recipients see before they even open the email.

How it works: Once your domain has a p=quarantine or p=reject DMARC policy in place, you can publish a BIMI DNS record pointing to a verified SVG logo file. ISPs that support BIMI (Gmail, Yahoo Mail, Apple Mail, and others) will display your logo in the inbox.

What a BIMI record looks like:

default._bimi.yourdomain.com  TXT  "v=BIMI1; l=https://yourdomain.com/logo.svg; a=https://yourdomain.com/bimi.pem"

Tag	Meaning
`l=`	URL to your SVG logo file
`a=`	URL to your Verified Mark Certificate (VMC) — required for Gmail

The VMC requirement: Gmail requires a Verified Mark Certificate (VMC) issued by a certificate authority to display your logo. These cost money (typically $1,000–$1,500/year) and require your logo to be a registered trademark. Yahoo and some other providers will display logos without a VMC.

Prerequisites for BIMI:

A DMARC policy of p=quarantine or p=reject (not p=none)
SPF and DKIM properly configured and passing
An SVG logo in the correct format (square, specific SVG profile)
A VMC if you want Gmail support

MonitorDMARC monitors your BIMI DNS record and will alert you if it changes or becomes unreachable.

MTA-STS and TLS-RPT¶

These aren't part of DMARC itself, but they're related and you may encounter them.

MTA-STS (Mail Transfer Agent Strict Transport Security): A standard that tells sending mail servers to only deliver email to your domain over encrypted connections (TLS), and to reject delivery if a valid certificate can't be verified. It helps prevent man-in-the-middle attacks on email in transit.

TLS-RPT: The reporting counterpart to MTA-STS. Similar to DMARC's RUA reports, TLS-RPT causes ISPs to send you reports about TLS connection failures to your mail servers.

Neither of these is required to use MonitorDMARC, but they're worth being aware of as part of a complete email security posture.

Quick Reference: What Each Thing Protects Against¶

Standard	What it does	What it protects against
SPF	Verifies the sending server is authorized	Unauthorized servers sending email in your name
DKIM	Cryptographically signs email	Tampering in transit; email spoofing
DMARC	Ties SPF/DKIM together and sets policy	Domain spoofing; tells ISPs what to do with failures
BIMI	Displays your logo in the inbox	Not a security control — builds trust and brand recognition
MTA-STS	Enforces encrypted delivery	Man-in-the-middle attacks on email in transit

The Recommended Path to Full DMARC Enforcement¶

If you're starting from scratch or cleaning up an existing setup, here's the general sequence that works for most organizations:

Audit your email senders. Before you change anything, make sure you know every service that sends email on your behalf — your mail server, your marketing platform, your CRM, your support tool, transactional email services, etc.
Publish SPF. Create an SPF record that includes all your authorized senders. Start with ~all (soft fail) while you verify coverage.
Set up DKIM. Configure DKIM signing for your primary mail server and every third-party service that sends on your behalf. Each service will give you a DKIM record to publish.
Publish a DMARC record at p=none. This starts the reporting flow without affecting any email delivery. Watch your reports — everything sending in your name will show up here.
Review your reports. Use MonitorDMARC to identify all sources of email for your domain. Investigate any failing sources — are they legitimate senders you need to add to SPF/DKIM, or are they unauthorized?
Fix authentication gaps. Add any missing legitimate senders to your SPF record and ensure DKIM is configured for them.
Move to p=quarantine. Once your reports show that legitimate email is consistently passing, tighten your policy to quarantine failing email.
Move to p=reject. After a period at quarantine with no issues, move to full rejection. At this point, any email that fails DMARC authentication is blocked before it reaches your recipients.

This process typically takes 4–8 weeks for a straightforward setup. More complex organizations with many email senders may take longer.