GLOSSARY

What is DMARC?

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a DNS policy record published at _dmarc.yourdomain.com that tells receiving servers what to do with mail claiming to be from your domain when neither SPF nor DKIM passes in alignment with the visible From address, and where to send reports about it.

Try Pinlyx free See the email inbox

Free forever plan · No credit card required · Cancel anytime

Quick definition

In one line: SPF and DKIM say who signed; DMARC says whether that matches the name on the letter, and what to do if it does not.

What it means

SPF validates an envelope sender nobody reads. DKIM validates a signing domain that need not match the brand in the message. Neither of them, alone, says anything about the From: line, which is the only sender identity a human ever sees. DMARC is the standard that ties the two together and makes them mean something: it requires that at least one of them pass and be aligned with the From domain, and it lets the domain owner state what should happen when neither is.

Alongside the policy it adds the piece everyone actually adopts it for: reporting. Receivers send back a daily XML summary of every source that sent mail claiming to be your domain, whether it authenticated, and what they did with it. For most organisations the first week of DMARC reports is the first complete inventory they have ever had of who sends mail as them.

The record, tag by tag

v=DMARC1: version. Mandatory and must be first, or the record is ignored entirely.
p=: policy for the organizational domain, one of none, quarantine or reject. Mandatory and must come second.
sp=: policy for subdomains. Absent, subdomains inherit p=. Set it explicitly the moment you use a subdomain for bulk sending.
rua=: where to send aggregate reports, as one or more mailto: URIs. This is the tag that pays for itself.
ruf=: where to send per-message failure reports. Most large receivers no longer send these for privacy reasons, so do not build a process around them.
fo=: which failures generate a forensic report. 0 only when everything fails, 1 when anything fails, d on DKIM failure, s on SPF failure.
adkim= and aspf=: alignment mode, r for relaxed (default) or s for strict. Relaxed accepts an organizational-domain match, so mail.example.com aligns with example.com. Strict demands an exact match.
pct=: percentage of failing mail the policy applies to. A rollout dial, covered in the FAQ.
ri=: requested aggregate report interval in seconds. 86400 is the default and effectively the only value honoured.

Alignment is the whole idea

If you take one thing from this page, take this: a green checkmark in a vendor dashboard is not a DMARC pass. The vendor is usually reporting that SPF and DKIM passed, which they will, because the vendor authenticates its own domains correctly. DMARC asks a harder question, and the failure mode is quiet, because your mail keeps being delivered right up until you publish a policy stronger than none.

The fix is nearly always the same and every serious vendor supports it: a branded sending domain. You publish CNAME records so that a subdomain of yours points at the vendor infrastructure, the vendor signs with d=yourdomain.com, and the envelope sender becomes bounce@mail.yourdomain.com. Both identifiers then align, and the same message that used to fail now passes twice.

Reading an aggregate report

Reports arrive as a gzipped XML attachment, one per receiver per day, and they are grouped by source IP rather than by message. Each record element carries a count, the disposition the receiver applied, and the SPF and DKIM results with their domains, which is exactly enough to tell an unauthenticated legitimate sender apart from an actual spoofer. Reading them by hand works for a small domain; past a few thousand messages a day you want a parser, because the volume is dominated by forwarding noise you need to filter out before the signal is visible.

The rollout that does not break payroll

Publish p=none with rua=. Nothing changes for any recipient. Reports start arriving within 24 hours.
Inventory. Every source in the report is either a system you own, a vendor you hired, a forwarder, or an abuser. Classify all four before touching the policy.
Fix alignment for the systems you keep: branded DKIM, custom return-path, one selector per sender.
Move to p=quarantine; pct=10, watch for a week, then raise to 100.
Move to p=reject, and set sp=reject so a forgotten subdomain cannot be used against you.
Keep reading the reports. A new vendor onboarded by a different team is the most common cause of a DMARC regression six months later.

What DMARC does not do

It does not stop lookalike domains. crmsol1d.com is a different domain with its own perfectly valid DMARC record. Brand protection is a registrar and monitoring problem.
It does not stop display-name spoofing. A message from a free webmail account with your CEO name in the display field passes its own domain policy.
It does not improve inbox placement by itself. It removes a reason to be filtered; reputation still decides placement. See domain warm-up.
It does not protect mail you receive. DMARC is a policy about your outbound identity. Inbound protection is your own filtering.

Related concepts

SPF: one of the two identifiers DMARC evaluates for alignment.
DKIM: the other one, and the more durable of the two.
List-Unsubscribe: the other half of the 2024 bulk sender requirements.
Bounce rate: a DMARC policy change shows up as a spike in 5.7.1 rejections.
Spam trap: authentication is necessary but never sufficient for deliverability.

How Pinlyx handles it

Sending domains connected to Pinlyx are set up for alignment from the start: your own DKIM selector, a bounce subdomain under your domain rather than ours, and a check that refuses to enable campaign sending while the From domain has no DMARC record at all. Aggregate reports can be routed to a mailbox synced into the CRM, so a daily XML attachment becomes a thread with an owner rather than an unread message in an alias nobody watches.

Record and report

What you publish, and what comes back.

A monitoring record, an enforcing record, and the XML that justifies the move between them.

Week one, and week twelve

; monitoring only, changes nothing for recipients
_dmarc.pinlyx.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@pinlyx.com; fo=1; adkim=r; aspf=r; ri=86400"

; enforcing, after the inventory is clean
_dmarc.pinlyx.com. 3600 IN TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@pinlyx.com; adkim=s; aspf=s; pct=100"

v= then p=, in that order, or the record is ignored. Strict alignment on both identifiers is a deliberate late-stage choice, not a default.

One record from an aggregate report

<record>
  <row>
    <source_ip>203.0.113.9</source_ip>
    <count>412</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>fail</dkim>
      <spf>pass</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>pinlyx.com</header_from>
  </identifiers>
  <auth_results>
    <spf><domain>bounces.vendor-mail.net</domain><result>pass</result></spf>
    <dkim><domain>vendor-mail.net</domain><result>pass</result></dkim>
  </auth_results>
</record>

Both raw results are pass, yet policy_evaluated shows dkim: fail. That field reports alignment, not validity: 412 legitimate messages that would have been rejected under p=reject.

What enforcement sounds like

550-5.7.1 Unauthenticated email from pinlyx.com is not accepted due to
550-5.7.1 domain's DMARC policy. Please contact the administrator of
550-5.7.1 pinlyx.com domain if this was a legitimate mail. Please visit
550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about
550 5.7.1  the DMARC initiative.  - gsmtp

Alignment truth table

Five real sending setups, and how DMARC scores them.

Setup	SPF	DKIM	DMARC verdict
Sent from your own MTA, signed with your key	pass, mailfrom bounce@pinlyx.com	pass, d=pinlyx.com	passBoth identifiers align. DMARC passes twice over.
Vendor with a shared bounce domain, branded DKIM	pass, mailfrom bounces@vendor-mail.net	pass, d=pinlyx.com	passSPF passes but does not align. The aligned DKIM signature carries the whole result.
Vendor with a shared bounce domain and a vendor DKIM key	pass, mailfrom bounces@vendor-mail.net	pass, d=vendor-mail.net	failTwo passes, zero alignment. DMARC fails, and under p=reject the mail is rejected.
Forwarded through a mailing list that appends a footer	fail, relay IP not listed	fail, body hash changed	failThe reason mailing lists rewrite the From header once you publish p=reject.
Subdomain sender, relaxed alignment	pass, mailfrom bounce@mail.crmsolid.com	none	passRelaxed alignment accepts an organizational-domain match, so this passes. Under aspf=s it would fail.

Watch out for

A green checkmark is not a DMARC pass.

Every email vendor dashboard shows SPF and DKIM as verified, and every one of them is telling the truth about its own domains. Alignment is a different question and no vendor can answer it for you, because it depends on the From address you put on the message. The only reliable source of truth is a raw message header from a real recipient, or your own aggregate reports.

If you check exactly one thing after publishing your record, send yourself a message from every sending system you own and read the Authentication-Results header on each. Five minutes there beats a week of guessing.

DMARC: FAQ

What teams ask between publishing p=none and daring to publish p=reject.

Alignment means the domain that passed authentication is the same domain the recipient sees in the From header. SPF alignment compares the envelope MAIL FROM domain with the From domain; DKIM alignment compares the signature d= tag with the From domain. A pass that is not aligned does nothing for DMARC, which is why a vendor can show you green checkmarks while your domain still fails.

No. DMARC passes when at least one of them passes in alignment. In practice you want both, because SPF alignment breaks whenever a vendor uses its own bounce domain and SPF itself breaks on forwarding, while DKIM keeps verifying across hops. Treat aligned DKIM as the primary signal and aligned SPF as the backup.

Long enough to read at least two full weeks of aggregate reports and recognise every sending source in them, which for most companies means three to six weeks because someone always finds a forgotten invoicing tool. Then move to p=quarantine with pct=10, raise the percentage as the reports stay clean, and only then go to p=reject. Jumping straight to reject is how a payroll notification ends up rejected on the first of the month.

It tells receivers to apply the requested policy to only that percentage of failing messages and to treat the rest one step down, so pct=10 with p=reject means roughly 10 percent rejected and 90 percent quarantined. It is a rollout dial, not a sampling of your traffic, and it never applies to p=none because there is nothing to apply. Remove it once you are at 100.

A list re-sends your message from its own servers, which fails SPF, and often appends a footer or rewrites the subject, which fails DKIM. With p=reject the receivers then reject a message a subscriber genuinely asked for. This is why most list software now rewrites the From header into a list address. ARC (RFC 8617) exists so a receiver can see the authentication result from before the list touched the message, but support is not universal.

No. Since February 2024 Gmail and Yahoo require bulk senders to publish a DMARC record on the From domain, and p=none satisfies that. They also require aligned SPF or DKIM, one-click unsubscribe on marketing mail, and a spam complaint rate kept below 0.3 percent, with 0.1 percent as the practical target. Publishing p=none and stopping there meets the letter of the rule and gives you none of the anti-spoofing benefit, so treat it as a starting line.

Keep reading

SPF

The envelope-sender check, its 10-lookup budget, and why it breaks on forwarding.

DKIM

The signature that survives relaying, and the one DMARC leans on hardest.

List-Unsubscribe

The other half of the 2024 Gmail and Yahoo bulk sender requirements.

Bounce rate

Read the rejection codes a policy change produces before your customers do.

Domain warm-up

Authentication gets you evaluated; reputation gets you delivered.

Email marketing automation

A practical guide to drips that convert, with the deliverability gotchas.

Ready to ship

Publish p=reject without breaking anything.

Pinlyx aligns your sending domain from day one, refuses to launch campaigns from an unauthenticated From address, and turns daily DMARC reports into threads with an owner.

Start free Talk to sales

Free forever plan · GDPR-ready · No credit card required