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
- RFC 9989: Domain-based Message Authentication, Reporting, and Conformance (DMARC), May 2026
- RFC 7208: Sender Policy Framework (SPF), section 4.6.4 processing limits
- Google: Email sender guidelines
- Google: Email sender guidelines FAQ
- Google Workspace: Send email from a printer, scanner, or app
- Microsoft Learn: Set up DMARC to validate email in Microsoft 365
- Microsoft Learn: How to use DKIM for email in your custom domain
- Shopify Help Center: Displaying your store's sending email
- Salesforce Help: Create a DKIM Key