Sample: a Mail Auth Fix Sheet

These are worked samples of what the $39 service returns. Sample 1 is Plainwork's own domain, read from live public DNS (one record missing). Sample 2 uses a domain that does not exist: shop.example, a reserved name, with a DNS zone we constructed to be messy (two SPF records, no DMARC). It shows DELETE and REPLACE with the old value next to the new, and the SPF budget before and after, each counted by the open-source checker reading that zone file. We never publish a sample about a real company that did not order one. Every DNS line in sample 1 can be re-checked with the free checker, every quotation is checked against the source page by a script, and the invented parts are marked ASSUMED. Back to the service.

Sample, produced by running the service's own playbook on a real public domain: Plainwork's own. Brief: domain plainworkdigital.com; senders: Resend (order and receipt emails) and Cloudflare Email Routing (forwards hello@ to a private inbox); problem: "no DMARC, want to be sure customer email passes before we enforce anything"; volume: under 100 messages a day. DNS read 2026-10-15 01:40 UTC over Cloudflare DNS-over-HTTPS. AI-written from public sources; not legal or compliance advice; no deliverability promise.

1. The answer first

1. Publish one new record: DMARC at p=none with a report address (section 4). It is the only thing missing. SPF and DKIM for both senders are already in place and nothing needs deleting.
2. Leave SPF alone. The root record uses 1 of 10 lookups, and Resend does not need an include at the root because it sends from the send subdomain.
3. Do not enforce yet. Forwarded mail through Cloudflare Email Routing is the part we cannot judge from DNS, so wait for two weeks of reports, then step up (section 6).

2. What we found

3. Your senders

4. Records to publish

Add (one record):

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected];
TTL:   Auto
Old:   none (the name does not exist today)

The rua address is ASSUMED: we do not know a mailbox you control, so we used [email protected]. It must exist before you publish the record. With Cloudflare Email Routing, create a routing rule that forwards that address to your inbox. The format follows Resend's own example, v=DMARC1; p=none; rua=mailto:[email protected];.

5. SPF lookup budget

Room left: 9 lookups. A future sender that supports a sending subdomain (as Resend does) costs the root record nothing.

6. Rollout plan (dates from the delivery date, 2026-10-15)

Resend's own advice matches: "we suggest starting with a policy of p=none; before moving to a stricter policy".

7. How to verify

• After each change, run dig +short TXT _dmarc.plainworkdigital.com (or nslookup -type=TXT _dmarc.plainworkdigital.com), or use the free checker at https://plainworkdigital.com/d20261015a8/email-auth-checker.
• In Gmail open a received message, choose Show original, and read the lines SPF, DKIM and DMARC: you want PASS on DMARC.
• Check the first aggregate report for any source you did not list.

8. What we could not establish

• Whether mail forwarded by Cloudflare Email Routing passes DMARC at its final destination: DNS cannot show it; the reports will.
• Any sender not named in the brief that uses the domain (marketing tools, a helpdesk): the reports will list them.
• DKIM selectors outside the 24 common names we probe: not-found is not "off".
• Microsoft's published requirement applies above 5,000 messages a day; your stated volume is under 100.

9. Sources (fetched 2026-10-15)

Sample 2: two SPF records, three senders, no DMARC (worked example on a constructed domain)

Same playbook, a messier domain. This domain is constructed for illustration. shop.example is a reserved name (RFC 2606) that cannot belong to anyone, and its DNS is a zone file we wrote and keep in the open-source repo (run the commands below from a clone of it) (examples/shop.example.json); it is not a real site and not a customer. The checker engine reads that file instead of live DNS, so every count and every record quoted below is produced by the same code as a real order. The senders (Fastmail for staff mailboxes, SendGrid for password resets and receipts, Mailchimp Transactional/Mandrill for member digests), the problem ("password reset emails land in Gmail spam") and the volume (about 3,000 a day, mostly Gmail) are ASSUMED. Vendor quotations in sections 3 and 8 are real and fetched 2026-10-15; the vendors' own SPF and DKIM names are shown as they appear in their setup pages.

1. The answer first

1. Fix SPF first: the root publishes two v=spf1 records, which receivers must treat as a permerror. Merge them into one record and delete the other (section 4). Until then SPF fails for every message, including the password resets.
2. Publish DMARC at p=none (section 4). There is no _dmarc record today, and Google's bulk-sender rules ask for one from 5,000 messages a day; at 3,000 a day you are below that line, but Yahoo asks for at least p=none.
3. Do not enforce yet. Keep DMARC at p=none for two weeks and read the reports before any quarantine step (section 6).

2. What we found

3. Your senders

4. Records to publish

DELETE the second SPF record:

Type:  TXT
Name:  @
Value: v=spf1 include:spf.messagingengine.com ?all
Action: DELETE (its include moves into the record below)

REPLACE the first SPF record:

Type:  TXT
Name:  @
Old:   v=spf1 include:sendgrid.net ~all
New:   v=spf1 include:spf.messagingengine.com include:sendgrid.net ~all
TTL:   Auto

The new record uses 3 of 10 lookups, counted by script (section 5). It ends in ~all, not the ?all Fastmail's page shows: that is our choice, so that unlisted senders are marked as soft failures rather than ignored. ADD DMARC:

Type:  TXT
Name:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:[email protected];
Old:   none (the name does not exist today)

The rua address is ASSUMED; the mailbox must exist before you publish.

5. SPF lookup budget

Room left after A: 7 lookups. Option B frees 2 more, but only after you have checked the dashboard: do not choose it from DNS alone.

6. Rollout plan (dates from the delivery date, 2026-10-16)

7. What we could not establish

• Whether SendGrid's em return-path is configured, and whether Mandrill needs any SPF text at all: UNKNOWN from DNS and from the pages we fetched.
• Which other services send as the domain: the DMARC reports will list them.
• Gmail placement of the password resets: not visible from DNS; fixing SPF removes one cause only.

8. Sources (fetched 2026-10-15)