Skip to main content

​
What is DMARC?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that protects your domain from being used in phishing and spoofing attacks. It works on top of two other protocols — SPF and DKIM — and adds a crucial missing piece: a policy that tells receiving mail servers what to do when an email fails authentication. Without DMARC, a failed SPF or DKIM check is just a signal. The receiving server decides on its own what to do — it might deliver the email, send it to spam, or reject it. With DMARC, you explicitly define the rules.

​
Why does DMARC matter?

Anyone can send an email that appears to come from your domain. This is called spoofing, and it’s how most phishing attacks work. A spoofed email might look like it’s from billing@acme.com, but it was actually sent by a malicious actor. DMARC prevents this by:
  1. Authenticating emails — checking that the email passes SPF or DKIM
  2. Enforcing a policy — telling receiving servers to reject or quarantine emails that fail
  3. Sending reports — giving you visibility into who is sending emails using your domain

​
How DMARC works

When a receiving mail server gets an email from your domain, it:
  1. Checks if the email passes SPF (is the sending server authorized?)
  2. Checks if the email passes DKIM (is the signature valid?)
  3. Checks alignment — does the domain in the “From” header match the domain used in SPF/DKIM?
  4. Looks up your DMARC policy to decide what to do if the checks fail
1

Email arrives

The receiving server runs SPF and DKIM checks.
2

DMARC evaluation

If at least one check passes and the domain is aligned — the email is delivered.
3

If both fail or alignment fails

The DMARC policy is applied: p=none delivers anyway (monitor only), p=quarantine sends to spam, p=reject blocks the email entirely.

​
Implementing DMARC

​
Step 1: Start with monitoring

Begin with a p=none policy. This tells receiving servers to deliver all emails regardless of authentication results, but send you reports so you can see what’s happening. Add this TXT record to your DNS:
FieldValue
TypeTXT
Name_dmarc.yourdomain.com
Valuev=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com;
TTL3600
The rua tag specifies where aggregate reports are sent. These reports show which servers are sending emails using your domain and whether they pass authentication.
Stay on p=none for at least 2–4 weeks. Review the reports to make sure all your legitimate email sources (SendKit, your own servers, marketing tools, etc.) are passing SPF and DKIM.

​
Step 2: Move to quarantine

Once you’re confident that all legitimate emails pass authentication, tighten the policy to p=quarantine. Emails that fail DMARC will be sent to the recipient’s spam folder. 
v=DMARC1; p=quarantine; rua=mailto:dmarc@yourdomain.com;
You can use the pct tag to roll this out gradually. For example, pct=20 applies the quarantine policy to only 20% of failing emails: 
v=DMARC1; p=quarantine; pct=20; rua=mailto:dmarc@yourdomain.com;
Increase the percentage over time as you gain confidence.

​
Step 3: Enforce with reject

The final step is p=reject. Emails that fail DMARC are blocked entirely — they never reach the recipient. 
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com;
This is the strongest level of protection. It completely prevents anyone from spoofing your domain.
Only move to p=reject when you are certain that all legitimate email sources for your domain are properly authenticated. A misconfigured reject policy will cause legitimate emails to be blocked.

​
DMARC record parameters

ParameterRequiredDescription
vYesVersion. Always DMARC1
pYesPolicy for the domain: none, quarantine, or reject
spNoPolicy for subdomains. Defaults to the p value if not set
pctNoPercentage of failing emails to apply the policy to (1–100). Default: 100
ruaNoEmail address to receive aggregate reports (e.g., mailto:dmarc@yourdomain.com)
rufNoEmail address to receive forensic (failure) reports
adkimNoDKIM alignment mode: r (relaxed, default) or s (strict)
aspfNoSPF alignment mode: r (relaxed, default) or s (strict)

​
Verifying your DMARC record

After adding the DNS record, you can verify it’s working by checking the email headers of a test email. Look for the Authentication-Results header: 
Authentication-Results: mx.google.com;
       dkim=pass header.d=acme.com;
       spf=pass (google.com: domain of hello@send.acme.com designates ... as permitted sender);
       dmarc=pass (p=REJECT sp=REJECT) header.from=acme.com
The dmarc=pass result confirms that your DMARC record is active and the email passed all checks.

​
FAQ

No. DMARC is optional for domain verification. However, we strongly recommend it. Without DMARC, anyone can spoof your domain, and some email providers may treat your emails with less trust.
Yes. The rua tag is optional. But without reports, you won’t have visibility into who is sending emails using your domain, making it harder to detect spoofing or misconfigured services.
Relaxed alignment (default) allows subdomains to pass. For example, an email from mail.acme.com passes DKIM alignment for acme.com. Strict alignment requires an exact match — mail.acme.com would fail alignment for acme.com. Relaxed is recommended for most setups.
At least 2–4 weeks. This gives you enough data to identify all legitimate email sources for your domain. If you have many services sending email on your behalf, you may need longer.