DMARC is a DNS record that tells receiving mail servers what to do with email that uses your domain in the From address but fails authentication. It works on top of SPF and DKIM and sends you reports on who is sending as you. To set it up, authenticate every service that sends your mail, publish a TXT record at _dmarc.yourdomain.com with p=none, then tighten to quarantine and reject.
People ask what is DMARC after one of two events. A bounce from Gmail, Yahoo or Outlook cites authentication, or a customer receives a fake invoice sent from the company's own domain. Both trace back to the same gap. The name stands for Domain-based Message Authentication, Reporting and Conformance, and the standard behind it changed in May 2026. This guide is general technical information, not legal or compliance advice.
On this page
- What is DMARC and what does it protect against
- How DMARC works with SPF and DKIM
- What a DMARC record looks like
- What changed in the DMARC standard in 2026
- Gmail, Yahoo and Outlook rules that require DMARC
- How to set up DMARC for your domain, step by step
- How to move from p=none to p=reject
- Worked example: DMARC for a 20-person company
- How to read a DMARC aggregate report
- Why DMARC fails for legitimate mail
- Should marketing email use a subdomain
- DMARC for domains that never send email
- What DMARC does not stop
What is DMARC and what does it protect against
Email has no built-in check on the From address. Anyone can send a message that displays billing@yourcompany.com, and the receiving server can't tell it is fake unless your domain publishes rules. DMARC is those rules. It tells Gmail, Yahoo, Outlook and every other receiver to deliver, quarantine or reject mail that fails, and to report back on what they saw.
The fraud it targets is expensive. The FBI 2025 Internet Crime Report logged 24,768 business email compromise complaints with $3.05 billion in losses, plus 191,561 phishing and spoofing complaints. Not every case spoofs the victim's exact domain. Exact spoofing is the cheapest attack to run, though, and a DMARC policy of p=reject shuts it down at every receiver that honors the policy.
DMARC also decides whether your own invoices and newsletters arrive. Google and Yahoo have required it from bulk senders since February 2024, and Microsoft followed for Outlook.com in May 2025. A bulk sender without a DMARC record now risks rejection at the three largest consumer mailbox providers before any filter reads the content. Authentication is one part of inbox placement; the rest is covered in the guide on how to improve email deliverability.
How DMARC works with SPF and DKIM
SPF and DKIM each prove something narrow. SPF lists the servers allowed to send for a domain. DKIM adds a cryptographic signature that the receiver checks against a public key in your DNS. Neither one, on its own, checks the From address the reader sees.
DMARC adds that check, called alignment. Under RFC 9989, the current DMARC standard, a message passes when SPF or DKIM passes and the passing domain aligns with the From domain. One aligned pass is enough. Each DKIM signature is checked on its own, so any one aligned signature passes the message.
Alignment has two modes, set by the adkim and aspf tags. Relaxed, the default, accepts any domain under the same organizational domain, so mail.example.com aligns with example.com. Strict requires the two domains to be identical. Keep relaxed unless you have a specific reason, because strict mode breaks mail that vendors sign with a subdomain.
A common failure looks like this. A CRM sends a newsletter that passes SPF for the CRM's own bounce domain and carries a DKIM signature for the CRM's domain. Both checks pass, nothing aligns with your From address, and DMARC fails. The fix is the vendor's custom DKIM setting, which signs your mail with your domain.
What a DMARC record looks like
A DMARC record is a TXT record published at _dmarc followed by your domain, so example.com publishes it at _dmarc.example.com. A starting record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
Tag | What it does | Typical value |
|---|---|---|
v | Version; must be the first tag | DMARC1 |
p | Policy for mail that fails; a valid record without p is treated as p=none | none, then quarantine, then reject |
rua | Address for daily aggregate reports | A mailbox or a DMARC report service |
ruf | Address for message-level failure reports | Optional; skip it at the start |
sp | Policy for subdomains that exist | Leave out to inherit p |
np | Policy for subdomains that do not exist | reject |
adkim, aspf | DKIM and SPF alignment mode | r (relaxed), the default |
t | Testing flag; t=y asks receivers to apply one level below p | y during each step up, then removed |
fo | When to send failure reports | 0, the default |
Publish one DMARC record per domain. Two TXT records at _dmarc can lead receivers to ignore both, so edit the record you have instead of adding a second one.
What changed in the DMARC standard in 2026
DMARC ran for 11 years on RFC 7489, an informational document published in March 2015, according to dmarc.org. In May 2026 the IETF published RFC 9989 on the Standards Track. It obsoletes RFC 7489 and RFC 9091, and two companion documents, RFC 9990 and RFC 9991, now define aggregate and failure reports.
- The pct tag is gone. Remove pct=25 or pct=50 from your record the next time you edit it.
- The t tag handles staged rollouts. With t=y, receivers apply one level below the published policy, so reject acts as quarantine and quarantine acts as none.
- The np tag sets a policy for subdomains that do not exist, which blocks spoofing from invented names such as payroll.example.com.
- The psd tag flags public suffix domains and matters to registries, not to a typical business.
- Receivers find the organizational domain with a DNS tree walk defined in the standard.
Existing records keep their meaning for the main tags. For most businesses, the 2026 update comes down to two edits: drop pct and add np=reject once the main domain is at enforcement.
Gmail, Yahoo and Outlook rules that require DMARC
Three providers set the floor for anyone sending marketing or transactional mail at volume. Google announced its rules on October 3, 2023, and Yahoo publishes its sender requirements on its sender hub. Microsoft added Outlook.com rules in 2025, summarized in Mailgun's guide to Microsoft sender requirements.
Provider | Who it applies to | DMARC requirement | Other requirements | Start |
|---|---|---|---|---|
Gmail | Senders of more than 5,000 messages to Gmail addresses in one day | SPF, DKIM and a DMARC policy | One-click unsubscribe processed within two days; stay under the spam rate threshold | February 2024 |
Yahoo | Bulk senders | Valid DMARC policy of at least p=none that passes, with the From domain aligned to SPF or DKIM; relaxed alignment is acceptable | SPF and DKIM; one-click unsubscribe honored within 2 days; spam rate below 0.3% | February 2024 |
Outlook.com, Hotmail.com, Live.com | More than 5,000 messages a day to Microsoft consumer domains | DMARC of at least p=none, aligned with SPF or DKIM | SPF and DKIM; failing mail rejected with error 550 5.7.515 | May 5, 2025 |
Gmail tightened enforcement in November 2025, moving non-compliant bulk mail from temporary deferrals toward permanent rejections. Google also treats bulk sender status as permanent once a domain crosses 5,000 messages in a day.
A p=none record satisfies all three providers today. It stops no spoofing at all, so treat compliance as the floor and p=reject as the goal.
How to set up DMARC for your domain, step by step
- List every service that sends mail as your domain. Start with Google Workspace or Microsoft 365 and your CRM, then add the email marketing platform, help desk, invoicing app, website forms and any server that sends password resets.
- Check SPF. Publish one SPF record that covers each sender, and keep it within the 10 DNS lookups that RFC 7208, the SPF standard allows. Past 10, SPF returns a permanent error.
- Turn on DKIM for each sender, with your own domain as the signing domain. Use 2048-bit keys where the provider offers them.
- Create an address for aggregate reports, such as dmarc-reports@yourdomain.com, or sign up with a report service.
- Publish the TXT record at _dmarc with p=none and the rua address. The change reaches receivers as DNS caches expire, which depends on the record's TTL.
- Confirm the record with a DNS lookup such as
dig TXT _dmarc.yourdomain.com, then send a test message to a Gmail account. Show original in Gmail lists the SPF, DKIM and DMARC results. - Read reports for at least 2 weeks and fix every legitimate source that fails alignment.
- Move to enforcement in stages, using the schedule in the next section.
How to move from p=none to p=reject
Enforcement is where a careless rollout blocks your own invoices. Run it in stages, and advance only when the reports show every legitimate source passing.
Stage | Record policy | How long | Move on when |
|---|---|---|---|
1. Monitor | p=none | 2 to 4 weeks | Every service you use shows aligned SPF or DKIM |
2. Test quarantine | p=quarantine; t=y | 1 to 2 weeks | No legitimate mail appears in failing rows |
3. Quarantine | p=quarantine | 2 to 4 weeks | No reports of missing mail from staff or customers |
4. Test reject | p=reject; t=y | 1 to 2 weeks | Failing rows show only unknown senders |
5. Reject | p=reject; np=reject | Ongoing | Review reports every week |
By this schedule, a small business reaches p=reject in 6 to 12 weeks. The durations are a recommendation, not a rule, and a domain with one or two senders can move faster.
Watch mailing lists before the last step. RFC 9989 tells domain owners to understand the problems a reject policy can cause for mailing lists and other legitimate mail. Lists that add a footer or change the subject break the DKIM signature. If staff post to such lists from the main domain, hold at quarantine or move list traffic to a subdomain with its own policy.
Worked example: DMARC for a 20-person company
Say a 20-person accounting firm in Ohio sends mail from five places. Staff use Google Workspace, newsletters go out through a CRM, and an invoicing app, a help desk and a WordPress contact form send the rest. Its first week of aggregate reports shows 4,200 messages using its domain.
Grouped by source, 3,100 come from Google Workspace and pass with aligned DKIM. The CRM sends 800 that pass SPF and DKIM for the CRM's own domains, so they fail DMARC. The invoicing app sends 150 invoices that fail the same way. The last 150 come from servers in three countries the firm has never used, and those are spoofing attempts.
The fix list is short. The firm turns on custom DKIM signing in the CRM and the invoicing app, and removes two SPF includes left over from an old provider. After two clean weeks at p=none, it steps through quarantine with t=y, full quarantine and reject with t=y over the next six weeks.
At p=reject, the 150 spoofed messages a week are refused by receivers that honor the policy, and the 950 vendor messages keep landing because they now align. The same inventory is worth doing before any CRM move, since a switch such as HubSpot vs Salesforce changes which servers send as your domain.
How to read a DMARC aggregate report
Aggregate reports arrive as XML files, one per receiver per reporting period. Each record groups messages by sending IP address and shows what happened to them.
Field in the report | What to look for |
|---|---|
source_ip | The server that sent the mail; look it up to name the service |
count | Messages from that IP in the period |
disposition | What the receiver did: none, quarantine or reject |
dkim and spf results | Pass or fail, and the domain each check passed for |
header_from | The From domain the reader saw |
Read each row against one test: is this a service the business uses. If yes and it fails, fix its alignment. If no, it is spoofing or an old system nobody remembers, and enforcement handles it.
Raw XML is slow to read by hand. Once a domain has more than three or four senders, a report service that parses the files and groups rows by source saves hours each month.
Why DMARC fails for legitimate mail
Cause | What the report shows | Fix |
|---|---|---|
Vendor signs DKIM with its own domain | DKIM pass for the vendor domain | Turn on custom DKIM for your domain in the vendor settings |
Vendor uses its own bounce domain | SPF pass for the vendor domain | Set a custom return path, or rely on aligned DKIM |
SPF record over 10 lookups | SPF permerror | Remove unused includes, or move some senders to a subdomain |
Forwarding | SPF fail from the forwarding server | Rely on DKIM, which survives forwarding when the message is unchanged |
Mailing lists that edit messages | DKIM fail | Hold at quarantine or send list mail from a subdomain |
Two DMARC records | No policy applied | Merge them into one record |
Fix vendor alignment first. It is the failure you can clear fastest, because each fix is a one-time setting in the vendor account.
Should marketing email use a subdomain
For any business that sends newsletters at volume, yes. Move bulk marketing to a subdomain such as news.example.com and keep staff mail and invoices on the main domain. Spam complaints from a campaign then land on the subdomain, and a mistake in a marketing platform setting cannot get your invoices rejected.
Each sending subdomain gets its own SPF and DKIM setup. It inherits the main domain policy through sp, or it can publish its own _dmarc record. A subdomain that exists falls under sp, while np covers names that do not exist at all, so set both once the main domain reaches p=reject.
Say an online store sends 40,000 promotional emails a week and 3,000 order confirmations. With promotions on news.example.com, a bad week of complaints after a holiday campaign counts against the subdomain. The 3,000 receipts on the main domain keep their own authentication record.
DMARC for domains that never send email
Parked and defensive domains are easy spoofing targets because nobody watches them. For a domain that never sends, publish v=spf1 -all as SPF and v=DMARC1; p=reject as DMARC, with an rua address if you want to see abuse. That is two DNS records per domain, and it closes the domain to exact spoofing at every receiver that checks DMARC.
What DMARC does not stop
DMARC protects your exact domain. It does not stop lookalike domains such as examp1e.com, or display names that put your company name over a free webmail address. It also can't help when a real mailbox is taken over with a stolen password. Those need staff training, multi-factor authentication and a call-back check for any bank detail change requested by email.
Start today by looking up your current record with dig TXT _dmarc.yourdomain.com and listing every service that sends as your domain. The email marketing team at Techno Mantra sets up SPF, DKIM and DMARC across Google Workspace, Microsoft 365, CRMs and marketing platforms. The team reads the reports and takes domains to p=reject without blocking real mail. Send your domain and the list of tools that send as you through the contact page or to info@technomantraa.com. Every inquiry gets a reply within one business day.
Frequently asked questions
For bulk senders, yes. Gmail, Yahoo and Outlook.com require a DMARC record of at least p=none from senders above their volume thresholds, which is 5,000 messages a day at Gmail and Outlook.com. No US law requires DMARC for most private businesses, but a missing record now costs deliverability.
Yes, for authenticated mail. A passing DMARC result meets the Gmail, Yahoo and Outlook.com bulk sender rules and gives receivers a reason to trust mail from your domain. DMARC does not fix poor list hygiene, high complaint rates or weak content, so pair it with clean lists and low complaint rates.
Yes, if you enforce too early. A p=reject policy tells receivers to refuse any message that fails alignment, including invoices from an app that signs with its own domain. Start at p=none, fix every legitimate sender shown in the reports, and step up with t=y before full enforcement.
Publishing the record takes minutes, and the first reports arrive within a few days. Reaching p=reject safely takes about 6 to 12 weeks for a small business with several senders, because each stage needs one to four weeks of clean reports before the next step.
Yes. DMARC is published on your domain, not inside the mail platform, and neither Google Workspace nor Microsoft 365 adds a DMARC record for your domain by default. Without one, anyone can spoof your domain, and bulk mail from your domain falls outside the Gmail and Yahoo rules.