Sample: DNS authentication setup
Domain: example.com · Scope: one requested domain's authentication records · Verification time: placeholder — actual UTC time goes here.
What we confirm before changing anything
- Where DNS is managed, and who will publish changes.
- The mailbox host and every other legitimate sender, such as a newsletter or invoicing service.
- Existing records and a rollback copy. No additional SPF record alongside an existing one.
Illustrative record changes
| Record | Before (example) | Planned change (example) |
|---|---|---|
| SPF | v=spf1 include:_spf.google.com ~all | After confirming both services send: preserve the Google include and add include:_spf.hostedemail.com before ~all. Review the SPF lookup limit. |
| DKIM | No record found at the requested selector | Publish the real public key supplied by the email provider at its exact selector. No key is invented in this sample. |
| DMARC | No record observed | Begin with a reviewed monitoring policy such as v=DMARC1; p=none. Tighten only after all legitimate senders are checked. |
| MX / website records | Existing routing | Preserve unless the agreed project includes a receiving-provider or website change. |
Verification evidence
A real report lists the lookup time, exact records seen, resolver used and any lookup failures. If a test message was sent, it records the sender, recipient and SPF/DKIM/DMARC results from the received headers. A DNS record alone does not prove that mail is signed or delivered to the inbox.
Remaining issues and next action
Example: newsletter sender access was unavailable, so alignment is not verified. Next: the customer supplies the provider's setup details; the operator reviews those before any stricter DMARC policy. The report identifies who owns that next step.
Limits: no inbox-placement guarantee, no implied old-mail migration, ongoing monitoring or completed customer outcome.