SPF & DMARC Record Generator

Free SPF and DMARC record generator

This SPF record generator and DMARC record generator builds the TXT records you publish in DNS. Enter the domain people see in From, list includes and IPs, pick an all policy, and set a DMARC policy plus a report mailbox. The tool counts SPF mechanisms that use DNS and warns before you blow the 10-lookup limit.

Here is the short version: one SPF record, DKIM on in your tenant, DMARC at p=none with reports, then quarantine, then reject. That path stops a large share of domain spoofing used in invoice and wire fraud.

Records are generated in your browser. Nothing is sent to Secure Techies.

What SPF should say

SPF is a public list of who may send mail for a domain. Official rules are in RFC 7208.

Common includes:

Publish one SPF TXT on the apex (or on the From domain). Two SPF records is a frequent self-inflicted outage.

Microsoft’s own email authentication guide walks through the Microsoft 365 include. Use it when the tenant is the primary sender.

What DMARC should say

DMARC tells receivers what to do when SPF or DKIM do not align with From. See RFC 7489.

A safe first record looks like:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; adkim=r; aspf=r; pct=100

Read aggregate reports for a few weeks. Forgotten tools (scanners, marketing platforms, printers) show up there. Then raise p to quarantine, then reject.

CISA recommends email authentication as a baseline control in its Cybersecurity Performance Goals. For law firms and anyone who wires money, reject is the destination, not a nice-to-have.

Rollout order that does not break mail

1. Inventory senders (Microsoft 365, Google, bill-pay, marketing, scanners).
2. Publish SPF with ~all if you are unsure.
3. Enable DKIM in the tenant.
4. Publish DMARC p=none with rua.
5. Fix gaps the reports show.
6. Move to quarantine, then reject.
7. Keep one owner for DNS changes.

Use the email header analyzer to confirm Authentication-Results after you publish.

Mistakes that waste a Friday

• A second SPF TXT “just for Mailchimp”
• +all because someone copied a 2008 blog
• Nested includes that push lookups past 10
• DMARC reject on day one with no report history
• Publishing DMARC on the wrong host (it belongs at _dmarc.domain.com)

DKIM, in one paragraph

This generator does not create a DKIM key pair. That belongs in the tenant (Microsoft 365 or Google) and then in DNS as a TXT at selector._domainkey.domain. Turn DKIM on before you raise DMARC. SPF-only alignment breaks more often when mail is forwarded. DKIM survives forwarding better. Microsoft’s email authentication overview covers the trio as one project, not three hobbies.

How this ties to the rest of the stack

Authentication does not replace inbox filtering, MFA, or a call-back rule for payment changes. It does make lookalike-From spoofs fail more often. That is the same theme as our wire fraud close call and our cybersecurity work.

After you publish, paste a test message into the email header analyzer. You want to see pass, not “we think we added the record.”

Worked example

Domain yourfirm.com, Microsoft 365 only, ready for hard fail:

• SPF: v=spf1 include:spf.protection.outlook.com -all
• Lookups: 1 (the include). Headroom is fine.
• DMARC host: _dmarc.yourfirm.com
• First DMARC: v=DMARC1; p=none; rua=mailto:dmarc-reports@yourfirm.com; adkim=r; aspf=r

Thirty days later, if reports show only Microsoft, raise p=quarantine. Then reject. If a scanner or a marketing platform appears, add its include or ip4 before you reject, or you will block your own mail.

Alignment, percent, and subdomain policy

Relaxed alignment (adkim=r and aspf=r) lets a subdomain pass as the parent. That is the usual start. Strict alignment is tighter and breaks more forwarding and some vendors. Do not turn on strict the same week you publish the first record.

pct applies the policy to a percentage of mail. Use it as a dimmer when you move from quarantine to reject if you are nervous. It is not a substitute for reading reports.

sp sets policy for subdomains. If marketing uses news.yourfirm.com and you do not control it, think before you set sp=reject. If you do not use subdomains for mail, matching p and sp is cleaner.

Reports, mailboxes, and who actually reads them

rua addresses receive XML aggregate reports. They are not pretty. Someone has to parse them or send them to a service that does. An unread dmarc-reports@ mailbox is the same as no DMARC. Set a calendar reminder for the first four Fridays after you publish p=none.

If you use a third-party report processor, their docs will give you a mailbox or a URI to put in rua. That is fine. Still keep an owner inside the firm.

Do not put a personal Gmail in rua for a company domain unless you like mixing work and a mailbox you will lose. Use a role address.

Third-party senders

Bill-pay, scanners, marketing tools, and “the printer that emails PDFs” all send as you. Inventory them. Add includes or ip4s. If you cannot find a vendor’s SPF include, ask them in writing. Then test. Then raise policy.

A law firm that adds Mailchimp the week after p=reject will learn about DMARC from bounced newsletters. That is the wrong classroom.

If you want this implemented and monitored on Microsoft 365, contact Secure Techies.