Do I need DMARC if I already have SPF and DKIM?

SPF and DKIM prove that a server was allowed to send or that a message was signed, but neither is tied to the address your reader sees in the From line. DMARC is the rule that requires one of them to pass for your own domain, and it is the only one of the three that sends you a report naming everything that sends as your domain. Gmail also asks senders of more than 5,000 messages a day to Gmail accounts to have all three in place.

Is p=none pointless if it does not block anything?

No. A record at p=none changes nothing about how receivers treat your mail, and that is the point: it buys you the daily aggregate reports without any delivery risk. It is also enough to satisfy the Gmail sender requirement, which states that the DMARC enforcement policy can be set to none. You move up to quarantine and reject later, once the reports show every legitimate sender aligned.

How long before I can move to p=reject?

Google suggests watching the reports for at least a week and confirming your own outgoing mail authenticates before moving to quarantine, then raising coverage over time before reject. In practice the timeline is set by your senders, not the calendar: a domain with Workspace and one invoicing system can be done in two or three weeks, while a domain with a CRM, a store, a newsletter tool and a scanner takes longer because each one has to be aligned on its own.

What is DMARC? How it works and how to set it up safely

A twelve-person accounting firm calls us in the last week of the month because their invoices stopped arriving. Not all of their mail: the messages people write by hand from Gmail still land fine. It is the ones the billing system sends that vanish. Somebody on a forum told them to set up DMARC, they pasted a record they found online, and by the afternoon the CRM had gone quiet too. That is a normal way to arrive at this topic, and it is fixable in an afternoon once you know what DMARC is actually checking.

DMARC is not a spam filter, and it is not a switch that makes your mail deliver better. It is a public instruction from you, the owner of the domain, to every mail server that receives a message claiming to be from you. It says two things: here is how to tell my real mail from mail that only claims to be mine, and here is what I want done with the mail that fails that test. Written down it is one line of DNS. Understood, it is the only part of email authentication that tells you who is sending as your domain.

The problem DMARC solves

Anyone can write your domain in the From line of a message. That is not a bug in a particular mail server, it is how the format works, and it is why a convincing fake invoice from your own domain is such a cheap attack. Two older mechanisms each close part of the gap.

SPF is a list, published in your DNS, of the servers allowed to send mail for your domain. DKIM is a signature added to the message itself, checked against a public key you publish in your DNS. Both are useful and both have the same blind spot: neither one is tied to the address your reader sees in the From line. A message can pass SPF for a completely different domain and still show your name to the person reading it.

DMARC is the rule that connects the two. It asks a further question, and then it does something almost no other part of email does: it sends you a report.

Alignment is the whole trick

To pass DMARC, a message has to pass SPF or DKIM, and the domain that passed has to match the domain in the From header that your reader sees. Google states both halves plainly in its own documentation: outgoing messages must pass either SPF or DKIM, and for direct mail the domain in the From header must be aligned with either the SPF domain or the DKIM domain. Passing one of the two is enough. Passing neither in a way that matches your domain is a DMARC failure, however clean the rest of the message looks.

There are two strictness settings for that match. Relaxed, which is the default, accepts a match at the level of the organisational domain, so mail signed for mail.example.com aligns with a From address at example.com. Strict requires the domains to be identical. Google's own troubleshooting guidance is worth repeating here: strict alignment can push legitimate mail from associated subdomains into spam, and relaxed alignment usually gives enough protection against spoofing. Unless you have a specific reason, leave it relaxed.

Alignment is also where the invoice problem in the first paragraph comes from. Say the billing system sends as facturacion@example.com but its servers use a return path on the vendor's own domain and sign with the vendor's DKIM key. SPF passes. DKIM passes. DMARC fails, because neither passing domain is yours. A record set to reject on day one turns that from an authentication detail into missing invoices.

Your first record: p=none and somewhere to send the reports

Order matters more than speed. Google's guidance is to have SPF and DKIM set up, and in place for at least 48 hours, before you enable DMARC. If you skip that, mail from your domain will probably have delivery problems.

The record is a single DNS TXT record on the _dmarc host of your domain. The v and p tags come first; the rest can be in any order.

Host:  _dmarc
Type:  TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc@example.com

p=none means: do not change how you treat my mail, just tell me what you are seeing. rua is the address where the daily aggregate reports arrive. Google recommends making that a group or a dedicated mailbox rather than somebody's personal inbox, and after the first week of XML attachments you will understand the recommendation. Reports are normally sent once a day, by each receiver that saw your mail.

Two more tags are worth knowing before a consultant offers them to you. sp sets a separate policy for subdomains that exist, and np sets one for subdomains that do not exist at all, which is how you stop somebody inventing facturas.example.com and sending from it. When np is absent, the policy from sp applies, and when sp is absent too, the policy from p applies. Both are defined in RFC 9989, the current DMARC specification.

Read the reports before you harden anything

This is the step people skip, and it is the only step that makes the rest safe. Each aggregate report is an XML file from one receiver covering one day of your mail: which IP addresses sent it, how many messages, whether SPF and DKIM passed, and whether they aligned with your domain. You are not reading it for the numbers. You are reading it to build a list of everything on earth that sends mail as your domain.

For a small business that list is longer than the owner expects, and it is usually some version of this: Google Workspace or Microsoft 365 for the people, the invoicing or accounting system, the CRM, the online store, the newsletter tool, the website contact form, a scanner in the corner of the office that mails PDFs, and one service nobody remembers signing up for. Go through it and put every sender in one of three groups.

Aligned already. Nothing to do. Most of your Workspace or Microsoft 365 mail lands here.
Yours, and failing. The ones to fix, one at a time, usually by turning on the vendor's DKIM signing for your domain or setting a custom return path. This is the real work of a DMARC project.
Not yours. Somebody sending as your domain who should not be. This is the group that justifies the whole exercise, and the reason you will eventually want a policy that is not none.

Moving up to quarantine, then reject

Google's recommended rollout is to watch the reports for at least a week, confirm your own outgoing mail is authenticating, then move to quarantine so failing mail goes to the spam folder where a recipient can still find it, starting with a small share of messages and raising it over time to all of them, and only then move to reject.

One correction to older guides, including plenty still online. They tell you to run that ramp with a pct tag in the record. RFC 9989, published in May 2026, replaced RFC 7489 as the DMARC specification and removed pct from the record syntax; the appendix covering the change is titled "Removal of the 'pct' Tag". What the specification keeps for a cautious rollout is the t tag, a signal that you do not want your stated policy enforced yet, which changes nothing about reporting and has no effect while the policy is none. The practical reading for a small domain: do not build your plan around a percentage. Get every sender on your list aligned, sit at quarantine for a week when someone is around to notice complaints, then go to reject. The safety comes from the inventory, not from the fraction.

It also helps to know what the big receivers ask of you, because it is less than people assume. Gmail requires senders of more than 5,000 messages a day to Gmail accounts to have SPF, DKIM and DMARC in place, and says plainly that the DMARC enforcement policy can be set to none. The same guidelines ask for the From header to align with the SPF or DKIM domain, a spam rate kept under 0.30% in Postmaster Tools, valid forward and reverse DNS, and TLS on the connection. So p=none satisfies the requirement. You move up to reject to protect your own domain from being used against your customers, not to satisfy Gmail.

The mistakes we fix most often

Almost every broken DMARC setup we are handed is one of these six.

Two records on _dmarc. A leftover from an earlier attempt sitting beside the new one. DMARC expects exactly one policy record, and with two published you effectively have none.
A rua address nobody can read. A typo in the mailto, or reports landing in a mailbox no human opens. The domain then sits at p=none for two years, which protects nothing and tells nobody anything.
Strict alignment copied from a blog post. It sounds safer and it is the setting most likely to send your own subdomain mail to spam.
Jumping straight to p=reject. The record is easy to publish and the damage is invisible to you, because the bounces go to the systems that send on your behalf, not to your inbox.
Forgetting the subdomain the marketing tool sends from. A policy on the root domain does not fix an unaligned sender on a subdomain, and sp exists for exactly this.
Expecting DMARC to survive forwarding. When a message is forwarded, SPF commonly breaks, because the forwarding server is not on your list. DKIM survives forwarding far better, which is a good reason to make sure DKIM is signing before you enforce anything.

How Guanacos Tech helps

On a deliverability project, this is most of what the work actually is: name every system that sends as the domain, read enough reports to be sure the list is complete, fix alignment one sender at a time, and stay on the reports long enough to know the fix held before the policy moves up. Nothing about it is clever. It is just ordered, and the order is what keeps invoices arriving. If you want to do it yourself with the record above and a week of reports, that is a perfectly good outcome. If the reports came back with nine senders and two you cannot identify, that is what our email deliverability consulting for small business is for. Bring your domain and one failing message to a 30-minute call and you will leave knowing which senders are the problem and what clearing them takes.

What is DMARC, and how to set it up without breaking your own email