Blog · Dmarc
How to Set Up DMARC: A Complete Beginner's Guide
What is DMARC and why does it matter?
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It is an email authentication standard that builds on SPF and DKIM, letting domain owners tell email receivers what to do with messages that fail authentication.
Without DMARC, receivers decide what to do with suspicious mail using their own rules. With DMARC, you set the policy explicitly: reject messages that fail authentication, quarantine them, or simply accept them and send you reports about what they saw.
When your DMARC policy is set correctly, attackers cannot send email that appears to come from your domain without being rejected or flagged. That protects your customers, your partners, and your brand from phishing and spoofing that uses your domain name without permission.
The monitoring phase requires reading aggregate reports - XML files that arrive in your inbox describing what each mail receiver saw. Most beginners find those reports difficult to read in raw form. DMARCFlow turns those XML reports into a readable dashboard, showing you which sources are passing or failing and flagging new sending infrastructure immediately. That is the practical tool you need before you move past the monitoring phase.
Before you start: the SPF and DKIM prerequisites
DMARC does not work alone. It requires SPF and DKIM to be in place first.
Think of it this way:
If you set up DMARC without SPF and DKIM, you will see a lot of failures and you will not know which legitimate sources are missing. You need to know which of your own systems send email before you can write a policy for what receivers should do with mail that is not from those systems.
Before you publish a DMARC record, do the following:
Skipping this audit is the most common reason DMARC setups fail. Organizations that publish DMARC without knowing their full sending footprint often find that their policy suddenly rejects legitimate email from a vendor or internal system they forgot to account for.
Step 1: Set up and test SPF
SPF uses DNS TXT records to list the IP addresses or hostnames of servers permitted to send email for your domain.
A basic SPF record for a domain that only sends email from its own mail server looks like this:
v=spf1 mx ip4:203.0.113.10 -all
This record says: the only servers allowed to send mail for this domain are the ones listed in the MX records, plus the specific IP address 203.0.113.10. The `-all` at the end tells receivers that any other source should be rejected.
To test your SPF record, use an SPF checker tool or send a test email to a service that shows you the authentication results, such as Mail-tester.com. The report should show an SPF pass for email sent from your authorized servers.
If you use a third-party email service such as SendGrid, Mailgun, or Microsoft 365, you need to add their include mechanism to your SPF record. For example, if you send through SendGrid, your record would look like:
v=spf1 include:sendgrid.net ~all
Replace `~all` (softfail) with `-all` (fail/reject) only after you have confirmed all legitimate sending sources are covered.
Step 2: Set up and test DKIM
DKIM adds a digital signature to the headers of your outbound email. Receivers use a public key published in your DNS to verify that the email was actually sent by someone with access to your private signing key and that the message was not altered in transit.
Most major email service providers set up DKIM for you automatically or provide a DNS TXT record you can add. A DKIM record for a selector might look like:
selector1._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA..."
The selector is chosen by your email provider. Some providers use multiple selectors for different sending streams.
To test DKIM, send a signed email to a testing address and check the authentication results. Many DMARC report analysis tools and email testing services will show you whether DKIM is passing for your domain.
The critical alignment rule for DKIM under DMARC is that the signing domain must match the domain in the From header of your email. If you sign mail from `marketing.example.com` but your From address shows `example.com`, that is a DMARC alignment failure even if DKIM passes.
Step 3: Publish your first DMARC record (p=none)
Once SPF and DKIM are working for all your legitimate sending sources, you are ready to publish your DMARC record.
Start with p=none. This tells receivers to accept all mail without changing their behavior, but to send you aggregate reports about what they see. This phase is for observation only. Nothing gets rejected.
A basic starter record looks like this:
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"
This record says:
Replace `example.com` with your actual domain. The subdomain prefix `_dmarc` is required for all DMARC DNS records.
Publish this record in your DNS and wait 24 to 48 hours for it to propagate. Then start collecting reports.
What each DMARC tag means: a plain-English breakdown
Here is what each tag in a DMARC record does:
For beginners, the most important tags are `v`, `p`, and `rua`. The others are for fine-tuning as you gain experience.
Step 4: Read your first aggregate reports
DMARC aggregate reports arrive at your rua=mailto: address as XML attachments. Opening raw XML is not practical for humans, so most operators use a tool to parse them.
This is where DMARCFlow becomes genuinely useful for beginners.
Raw aggregate reports tell you which mail servers are sending email that claims to be from your domain. The report lists each sending source, whether it passed or failed SPF and DKIM alignment, and what the receiver did with the message. In a properly configured setup, every source should pass. If you see failures from sources you recognize, that means something in your SPF or DKIM setup is wrong. If you see failures from sources you do not recognize, that is likely spoofing attempts that your policy is catching.
The specific things to look for in your first reports:
Do not rush to p=quarantine or p=reject. Stay at p=none for at least two to four weeks, or until your aggregate reports show zero unexpected failures from legitimate sources.
Step 5: Move from p=none to quarantine to reject safely
The standard progression is: none, then quarantine, then reject.
Each stage has a purpose:
The only way to know when you are ready for the next stage is the aggregate reports from the current stage. If your reports show that every legitimate source consistently passes DMARC, you are ready to consider moving to p=quarantine.
Move gradually:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=10
This applies the quarantine policy to only 10% of messages, letting you catch any sources that were failing silently before a full rollout.
Raise `pct` in stages: 10%, then 25%, then 50%, then 100%, watching reports at each step.
Only move to p=reject once quarantine has run at 100% for at least a week with no complaints about missing legitimate mail.
Common DMARC setup mistakes and how to avoid them
**Publishing DMARC before auditing sending sources.** This is the most common beginner mistake and the most disruptive. Always know what is sending before you set a policy.
**Using `-all` in SPF before all sources are documented.** If you add `-all` (hard fail) to your SPF record before including all your sending systems, email from undocumented sources will bounce immediately. Use `~all` (softfail) during testing.
**Setting pct to 100 immediately when you move to quarantine or reject.** Unexpected failures happen. Use pct to throttle the impact.
**Ignoring aggregate reports.** p=none without reviewing reports is pointless. The whole point of the monitoring phase is to find problems before they become email outages.
**Forgetting subdomains.** If you have subdomains that send email, make sure they have their own SPF and DKIM records and their own DMARC policy or explicit inclusion in your main policy via the `sp` tag.
**Setting rua to the same domain you are monitoring.** Use an address on a domain that will not be affected if your main domain's email breaks.
DMARC setup checklist
Use this checklist before you publish any policy above p=none:
How DMARCFlow helps you monitor without breaking your email
DMARCFlow turns the XML aggregate reports that arrive in your inbox into a human-readable dashboard. It shows you which sources are passing and failing, which subdomains are sending mail without proper authentication, and when new sending infrastructure appears in your reports.
For teams that are new to DMARC, the most valuable feature is the ability to see all receivers in one view. If your email goes to Gmail, Microsoft 365, and a dozen other providers, each one sends reports separately. DMARCFlow aggregates them into a single timeline so you can see the full picture instead of hunting through individual mailbox reports.
The other practical advantage is change detection. When a new source starts sending mail as your domain, DMARCFlow flags it immediately. That is useful during normal operations when you onboard a new email system, and it is critical when the new source is an attacker spoofing your domain.
Start at p=none with DMARCFlow monitoring your aggregate reports. Raise your policy only when DMARCFlow shows all your legitimate sources consistently passing. That is the safe path to enforcement.