DocumentationAPI ReferenceKnowledge Base
Domains & Authentication

DMARC explained: policy, alignment, and rollout

What DMARC is, why MailBlastr starts you at p=none, how to monitor and then tighten to quarantine or reject, and how alignment works through the SPF MAIL FROM and DKIM.

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer that ties SPF and DKIM together. It is a single TXT record at _dmarc.yourdomain.com that tells receiving mail servers two things: what to do with mail claiming to be from your domain that fails authentication, and where to send reports about it.

MailBlastr generates a DMARC record for you starting at the safest setting — p=none — so you can publish it immediately without any risk of legitimate mail being blocked while you confirm everything is aligned.

The record MailBlastr generates

DMARC — TXT
TypeTXToptional

DMARC policy record.

Name_dmarc.yourdomain.comoptional

The standard DMARC hostname.

Valuev=DMARC1; p=none;optional

A monitoring policy to start with. Tighten the p= value once you trust your alignment.

TTLAutooptional

Provider default.

How alignment works

DMARC passes when a message is authenticated and aligned by SPF or DKIM (either one is enough):

DKIM alignment — the message carries a valid DKIM signature (via the mailblastr._domainkey.<domain> TXT record holding your public key) and the signing domain matches your from domain.

SPF alignment — SPF passes for the message’s MAIL FROM (envelope) domain, and that domain aligns with your from domain. MailBlastr’s custom MAIL FROM subdomain send.yourdomain.com exists precisely to give you this alignment: the SPF TXT v=spf1 include:amazonses.com ~all authorizes MailBlastr to send for that subdomain.

Because a verified domain already publishes both DKIM (the public-key TXT) and SPF (the MAIL FROM MX + TXT), DMARC alignment is satisfied out of the box for mail you send through MailBlastr. See DNS records.

Rolling out: none → quarantine → reject

Tighten your policy in stages. Move up only once your reports show that legitimate mail is consistently passing DMARC.

  1. 1
    Start at p=none (monitor)

    Publish v=DMARC1; p=none; (what MailBlastr generates). Receivers take no action on failing mail, so nothing legitimate is affected. Add a rua=mailto:dmarc@yourdomain.com tag to collect aggregate reports and watch which sources pass and fail.

  2. 2
    Confirm DMARC is passing

    Before tightening, send a message from every application and service that uses your domain (not just MailBlastr) and inspect the received headers for dmarc=pass. Tools like Google Postmaster Tools and DMARC monitoring/aggregation services help you discover any other sources sending as your domain — catch the ones that mail on a weekly or monthly cadence, not just daily.

  3. 3
    Move to p=quarantine

    Once reports show your real mail (MailBlastr and any other legitimate senders) passing, raise the policy to p=quarantine; so failing mail is sent to spam rather than the inbox. Consider pct= to ramp gradually.

  4. 4
    Move to p=reject

    When you are confident everything legitimate is aligned, set p=reject; so receivers drop spoofed mail outright. This gives you the strongest protection against impersonation of your domain.

Tag reference

DMARC tags
vrequiredoptional

Protocol version — always v=DMARC1.

prequiredoptional

Policy for the organizational domain: none (monitor), quarantine (spam folder), or reject (block).

spoptionaloptional

Policy for subdomains of the domain (e.g. sp=reject). Lets you apply a different, often stricter, policy to subdomains than the root.

ruaoptionaloptional

Address that receives aggregate (daily-summary) XML reports — e.g. rua=mailto:dmarc@yourdomain.com. Essential during the none monitoring phase. May point to a different domain than the one being protected.

pctoptionaloptional

Percentage of failing mail the policy applies to (e.g. pct=20), useful for a gradual ramp.

rufoptionaloptional

Address for forensic (per-message failure) reports — e.g. ruf=mailto:authfail@yourdomain.com.

adkimoptionaloptional

DKIM alignment mode: r (relaxed, default) or s (strict, signing domain must match exactly).

aspfoptionaloptional

SPF alignment mode: r (relaxed, default) or s (strict).

Although pct and ruf are part of the DMARC spec, they are not widely honored by mailbox providers — don’t rely on either being respected. Use p=, rua=, and (for staged subdomain control) sp= as your primary levers.
Raise the policy at your DNS provider only after monitoring. Jumping straight to p=reject before confirming alignment can cause receivers to drop legitimate mail from sources you forgot about (e.g. a separate CRM or help-desk tool sending as your domain).

Related: DNS records for the SPF and DKIM records DMARC builds on, and What if my domain isn’t verifying? if the underlying records are not resolving yet.