What is DMARC and why does your business need it?
· 5 min read · Randy Hall
What DMARC does
DMARC is an email security system that stops scammers from sending messages that appear to come from your domain. Without it, anyone can send email claiming to be you, and most mail systems will deliver it.
How email impersonation works
When you send an email, the "From" address your recipient sees is just text. There is nothing stopping someone else from typing your domain into that field and sending mail that looks identical to yours. This is called spoofing, and it happens constantly.
Your customers receive an invoice that looks like it came from you. Your suppliers get a request to change bank account details. Your employees see what appears to be a message from the CEO. The recipient has no way to tell the difference unless you have published the right DNS records.
The three records that work together
DMARC does not work alone. It relies on two other systems, SPF and DKIM, to verify that email is genuine.
SPF
Sender Policy Framework is a DNS record you publish at your domain. It lists the IP addresses and servers allowed to send email on your behalf. When a mail server receives a message claiming to be from you, it checks whether the sending server is on your SPF record.
An SPF record looks like this:
`v=spf1 include:_spf.google.com ~all`
That example permits Google Workspace to send mail for your domain. The `~all` at the end is a soft fail, meaning "treat mail from other servers as suspicious but deliver it anyway." A hard fail is `-all`, which tells the receiving server to reject the message outright.
SPF has limits. It only checks the envelope sender, not the "From" address the recipient sees. It also breaks when email is forwarded, because the forwarding server is not on your SPF record.
DKIM
DomainKeys Identified Mail attaches a cryptographic signature to each outgoing message. You publish a public key in DNS, and your mail server signs every email with the matching private key. The receiving server fetches your public key and verifies the signature.
A DKIM record is published as a TXT record at a subdomain like `default._domainkey.yourdomain.com`. It looks like this:
`v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...`
Unlike SPF, DKIM survives forwarding because the signature travels with the message. But DKIM alone does not prevent spoofing, because a scammer can sign their own mail with their own key and it will pass DKIM validation. DKIM only proves the message was not altered in transit.
DMARC
DMARC ties SPF and DKIM together and tells receiving servers what to do when a message fails. You publish a DMARC record as a TXT record at `_dmarc.yourdomain.com`.
A basic DMARC record looks like this:
`v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com`
The `p=` tag is the policy. It has three possible values:
- p=none — monitor only. The receiving server checks SPF and DKIM but takes no action. You receive reports about what passed and what failed.
- p=quarantine — put suspicious mail in the spam folder.
- p=reject — refuse delivery entirely.
The `rua=` tag specifies where to send aggregate reports. These are XML files summarizing the authentication results for mail claiming to be from your domain. Most businesses need a third-party service to parse these reports, because the raw XML is not human-readable.
Why p=none is not protection
Many businesses publish a DMARC record with `p=none` and assume they are protected. They are not. The `p=none` policy does nothing to prevent spoofing. It only enables monitoring.
A scammer can still send email pretending to be you, and it will still be delivered. The only difference is that you will receive a report about it afterward. That is useful information, but it does not stop the attack.
To actually prevent spoofing, you must set `p=quarantine` or `p=reject`. This is called enforcement.
Moving from monitoring to enforcement
You should not jump straight to `p=reject`. Start with `p=none` and collect reports for at least two weeks. Look for legitimate email sources you forgot to add to your SPF record. Marketing platforms, CRM systems, accounting software and ticketing tools often send email on your behalf.
Once you are confident your SPF and DKIM records are complete, change the policy to `p=quarantine` and monitor for another two weeks. If no legitimate mail is quarantined, move to `p=reject`.
This process typically takes four to six weeks. Rushing it will cause your own email to be rejected.
What happens if you do nothing
A domain without DMARC enforcement can be spoofed by anyone. The barrier is negligible. Scammers use your domain to send phishing emails, and your customers assume you have been breached. Your domain reputation declines, which makes it harder for your legitimate email to reach the inbox.
Some large receivers, including Gmail and Yahoo, now require DMARC for bulk senders. If you send more than 5,000 messages per day to Gmail addresses, you must have DMARC enforcement in place or your mail will be rejected.
Checking your current configuration
You can check whether your domain has SPF, DKIM and DMARC records by querying DNS directly or using an online tool. If you use ActiScore to audit your website, the Security category includes DNS checks for SPF, DMARC and DKIM, along with TLS certificate health and other email authentication settings.
If you find your records are missing or misconfigured, your email provider or IT administrator can help you publish the correct ones. Most email platforms provide step-by-step instructions for setting up SPF, DKIM and DMARC.
Summary
SPF lists who can send email for your domain. DKIM signs your messages. DMARC tells receiving servers what to do when SPF or DKIM fails. Together, they prevent scammers from impersonating you.
A DMARC record with `p=none` is a first step, but it is not protection. Only `p=quarantine` or `p=reject` will stop spoofed email from reaching your customers. The transition takes several weeks, but the alternative is leaving your domain open to anyone who wants to use it.
Common questions
Can someone send email pretending to be me if I don't have DMARC?
Yes. Without DMARC enforcement, anyone can send email using your domain in the "From" address, and most mail servers will deliver it. The recipient sees what looks like a legitimate message from you. DMARC with a policy of p=quarantine or p=reject tells receiving servers to block or flag those spoofed messages. A policy of p=none only monitors the problem without stopping it.
What is the difference between p=none, p=quarantine and p=reject?
The p= tag in your DMARC record tells receiving mail servers what to do with messages that fail authentication. p=none means monitor only—spoofed mail is still delivered, but you get reports. p=quarantine sends failed messages to the spam folder. p=reject blocks delivery entirely. You should start with p=none, verify your legitimate email sources are authenticated, then move to p=quarantine and finally p=reject over a period of several weeks.
Do I need DMARC if I use Gmail or Microsoft 365?
Yes. Gmail and Microsoft 365 handle outgoing authentication for you—they sign your mail with DKIM and include your domain in SPF—but they do not publish a DMARC enforcement policy on your behalf. You must add the DMARC record yourself in your DNS settings. Without it, scammers can still spoof your domain. Both providers offer documentation on how to set up DMARC for domains hosted with them.
How long does it take to set up DMARC properly?
Publishing a DMARC record takes minutes, but moving from monitoring to enforcement should take four to six weeks. You need time to collect reports, identify all the services that send email on your behalf, and update your SPF and DKIM records accordingly. Rushing this process risks blocking your own legitimate email. Start with p=none for at least two weeks, then p=quarantine for another two weeks before switching to p=reject.
What are DMARC aggregate reports and do I need to read them?
DMARC aggregate reports are XML files sent by receiving mail servers to the address you specify in the rua= tag. They summarize which messages passed or failed SPF and DKIM authentication. The raw XML is difficult to read, so most businesses use a third-party service to parse and visualize the data. These reports are essential during the monitoring phase because they show you which legitimate senders you need to add to your SPF record before enforcing a stricter policy.