← Back to Blog

Before you set DMARC to p=reject: the third-party sender checklist

  • Gmail
  • Admin console
Before you set DMARC to p=reject: the third-party sender checklist

Why p=reject fails silently for the senders you forgot

Say a 12-person accounting firm finishes what looks like a clean DMARC rollout. Mail from Google Workspace passes, the newsletter passes, two weeks of reports look tidy, and somebody flips the policy to p=reject on a Friday afternoon. On Monday a client calls to ask where the invoice went.

Nobody inside the firm saw a bounce. A rejected message is refused at the receiving server, and the refusal goes back to the envelope sender, which here is the billing platform, not a person at the firm. The mail stopped quietly, and the first signal was a customer who paid late.

That is the failure mode of enforcement. It does not break the senders you tested. It breaks the ones nobody wrote down: the invoicing tool, the scanner in the hallway, the booking system's reminders, the store's shipping notices, the helpdesk that replies as support@. Each puts your domain in the From line and signs with somebody else's, and until the policy had teeth, receivers let it through.

So the real work before p=reject is not DNS work. It is an inventory. Here is the checklist we run on a client domain, in the order we run it.

Build the sender inventory from the aggregate reports

Guessing gives you a list of the senders you already knew about. The aggregate reports give you the real one, including the tool a department signed up for last year without telling anyone.

Leave the policy at p=none with a rua address for at least two weeks, and a full month when the business has a monthly billing or payroll cycle. A sender that fires once a month will not appear in a two-week window, and that is usually the sender that hurts.

Then read the reports and write down, for every source: which vendor the IP belongs to, whether SPF passed and aligned, whether DKIM passed and aligned, and roughly how many messages. Alignment is the column that decides everything. RFC 9989, published in May 2026 as the standards-track replacement for RFC 7489, keeps the same rule at the centre: one of SPF or DKIM has to pass and match the domain in the visible From header. A vendor whose SPF passes on the vendor's own domain contributes nothing.

If reading raw XML is not how you want to spend the afternoon, paste a report in instead.

Sort every line into three buckets. Yours and aligned, which needs nothing. Yours and not aligned, which is the work. Not yours at all, a forwarder or somebody spoofing you, and neither should stop the rollout.

What to configure, category by category

Nearly every unaligned sender is fixed by one of three moves: get the vendor signing DKIM with your domain, move that mail onto a subdomain you delegate, or relay through your own mail platform instead. Which move applies is mostly a property of the category.

Marketing and newsletter platforms

These are the easiest, because every serious platform supports custom DKIM. Publish the CNAME records the vendor gives you, wait for them to resolve, then turn on signing.

One detail catches people out. Several platforms, Mailchimp and HubSpot among them, do not let you move the return path onto your own domain, so SPF keeps reading as a pass on their domain and a fail on alignment, permanently. That is fine: only one identifier has to align, and DKIM is the one you control. Do not paste the vendor's include: into SPF hoping to fix that column, because it cannot align and it spends one of your ten lookups. We went through each of these in why Mailchimp, HubSpot and Klaviyo fail DMARC alignment.

CRM and sales tools

Salesforce is the pattern here. Its documentation has you create a DKIM key in Setup, choosing an RSA key size, with 2048 bits recommended, and a selector that identifies the key. What matters for DMARC is signing with your From domain rather than a vendor default. Salesforce also documents an email relay option that routes outbound mail through your own server, Workspace or Microsoft 365 included, which solves SPF alignment too because the mail genuinely leaves your platform.

Sales tools that send from an individual's mailbox over an authorised connection usually align already, since the message really does leave Workspace or Exchange Online. Verify rather than assume.

Invoicing, accounting and the back office

This is the category that breaks quietly and costs money when it does. Invoices, statements, payroll notices and receipts go out monthly, so they are under-represented in a short reporting window, and the recipient is a customer who will not call to say the invoice never arrived.

Three outcomes are common. The tool supports custom DKIM, which is the clean answer. It lets you supply your own SMTP credentials, so you point it at your mail platform and it inherits your authentication. Or it offers neither and sends as you with no way to sign, and then the honest fix is to change the From address: onto a subdomain you delegate to that vendor, or onto the vendor's domain with your company in the display name and a reply-to that comes back to you.

Stores, booking systems and their email apps

Shopify is representative of the category. Its help centre has you add CNAME records at your DNS provider to authenticate the sending domain, and sets two conditions on the DMARC record itself: the domain must have only one DMARC TXT record, and it should not be on strict alignment, adkim=s or aspf=s. If the check does not pass, Shopify rewrites the visible sender to an address on its own domain, precisely the outcome you were trying to avoid. Those DNS changes can take up to 48 hours.

Helpdesk and shared inboxes

Helpdesks reply as support@ or hola@ from their own infrastructure, so they need the same DKIM treatment as a marketing platform. The sequence is what matters: add the external address, publish the DKIM records the vendor gives you, confirm they resolve, and only then enable signing in the vendor console. In the other order, the vendor signs with a key that does not resolve and mail that used to pass starts failing.

The office printer and the line-of-business app

The multifunction printer in the hallway scans to email. So does the alarm panel, the backup software, the point of sale, and whatever script somebody wrote in 2021. None appear on a vendor list, all use your domain, and several only send when something is wrong, the worst possible time for a message to be refused.

For Google Workspace tenants, Google documents sending from a printer, scanner or app through the SMTP relay service, which relays the message through Google so it carries your DKIM signature instead of nothing. Devices authenticate with credentials or by IP address, the practical option for a printer. Your SPF record needs Google authorised, which it almost certainly already is:

example.com.  TXT  "v=spf1 include:_spf.google.com ~all"

For Microsoft 365 tenants, the trap sits one step earlier. Microsoft's documentation is explicit that DKIM signing must be configured for your custom domain so the signing domain aligns with the From address. A tenant that never did this signs with its .onmicrosoft.com domain, and mail from Exchange Online then passes SPF, passes DKIM, and still fails DMARC. If your reports show Microsoft ranges failing alignment while everything looks configured, that is nearly always why.

Where a device cannot authenticate at all, give it a subdomain and leave the main domain clean. A scanner sending as scans@notify.example.com is a contained problem. The same scanner as scans@example.com is a reason not to enforce.

Two limits that bite during the inventory

Every vendor you add tempts you to paste another include: into SPF, and the record has a ceiling. RFC 7208 section 4.6.4 caps a single SPF evaluation at ten DNS-querying mechanisms, and going over produces a PermError, which fails SPF for every message regardless of origin. So the working rule through the inventory: DKIM is how you align a third party, SPF is for the handful of systems that genuinely relay your mail, and an include leaves the record the same week the vendor does. If you are already over the limit, getting back under ten lookups comes before any policy change.

A week at quarantine, then reject

Once every line is aligned or deliberately moved off the domain, tighten in two steps rather than one.

The percentage dial you may remember from older guides is gone. RFC 9989 removed the pct tag and put a plain testing flag in its place, t=y, which reports without enforcing. Records that still carry pct stay valid, but a staged percentage is no longer something to build a rollout on. Stage with the policy value itself.

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Quarantine turns a hard failure into a soft one. Anything you missed lands in a spam folder instead of vanishing, and the recipient can still find it and tell you. Watch the reports daily that week, and if the business has a billing run, schedule the week so the run falls inside it.

Then move to enforcement:

_dmarc.example.com.  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Keep the rua address in the record permanently. The inventory is a snapshot, and somebody will buy a new tool in March. If subdomains are part of your plan, the sp tag decides what happens to them, and that has its own traps.

Worth knowing before you set a date: a domain sending more than 5,000 messages a day to Gmail already has to publish a DMARC policy, keep its spam complaint rate below 0.3 percent and support one-click unsubscribe on bulk mail, enforced by Google since February 2024. Reaching p=reject goes beyond that, and the inventory makes it safe rather than brave.

How Guanacos Tech helps

We run this as a defined piece of work for small and mid-sized companies in North America and Latin America, in English and Spanish: a month of aggregate reports, the sender inventory, alignment fixed vendor by vendor, a quarantine week, then the reports watched through the first weeks of enforcement so a missed sender turns into a phone call instead of a lost invoice. The surprise is rarely a spoofer. It is almost always a tool one department bought and nobody else knew about.

Start on your own if you like: the DMARC analyzer and the email troubleshooter are free and need no account. To hand it over instead, our email deliverability consulting for small business page explains how an engagement runs, and a 30-minute call is enough for us to read your record and name the senders standing between you and p=reject. Vendor documentation cited here checked 24 September 2026.

Sources

Next step

Would you rather we did this for you?

Thirty minutes on Google Meet, free. We look at your domain or project with you, tell you what is wrong and what we would do first. If you can fix it yourself, we say so.

Book a 30-minute call or read about our email deliverability service

Frequently asked questions

How long should I stay at p=none before moving to p=reject?

Two weeks is the minimum, and a full month is better when the business bills or runs payroll monthly. Senders that fire once a month do not appear in a two-week reporting window, and those are usually the ones that break when enforcement starts.

A vendor cannot sign DKIM with my domain. What are my options?

Three, in order of preference. Point the tool at your own mail platform with SMTP credentials so it inherits your authentication. Move that mail to a subdomain you delegate to the vendor. Or change the From address to the vendor's domain with your company in the display name and a reply-to that comes back to you.

Does SPF have to align if DKIM already does?

No. DMARC passes when either SPF or DKIM passes and aligns with the domain in the visible From header. Several marketing platforms never let SPF align because the return path stays on their domain, and those messages pass DMARC on DKIM alone.