mailforge
v0.1.0 · spf · dkim · dmarc builder, validator & repair / runs in your browser · RadMage LabsSPF record builder and validator
SPF lists the servers allowed to send mail using your domain in the envelope (Return-Path). Publish exactly one SPF record per host name; two records make SPF fail for every message. RFC 7208
check an existing record
paste one or more records, or fetch what is published
build
terms are evaluated top to bottom; the first match wins
How the terms work
ip4/ip6 authorize addresses and cost no DNS lookups. a, mx, include, exists, ptr and redirect each cost one of the 10 lookups a receiver allows, and included records spend from the same budget.
The qualifier sets the result when a term matches: + pass (default), ~ softfail, - fail, ? neutral. End with ~all or -all; +all authorizes the whole internet.
Several values can be added at once, separated by spaces or commas. New terms go in before all.
Check each provider's own documentation; these values rarely change, but they can. Barracuda has separate includes for its other regions (au, ca, de, in, uk), such as spf.ess.uk.barracudanetworks.com. SendGrid and Mailgun usually send from their own subdomain of yours (such as em1234 or mg) and give you that subdomain's SPF record; add them here only if mail is sent from this exact domain.
record & checks
dns output
copy into your DNS host
DKIM record builder and validator
DKIM publishes the public key receivers use to verify signatures your mail server adds. The key lives at selector._domainkey.domain. Long keys need several strings in one TXT record. RFC 6376 · RFC 8301 · RFC 8463
check an existing record or key
TXT record, zone-file / opendkim output, or a PEM public key
Never paste a private key; MailForge refuses them. Everything stays in this page either way.
build
the public key comes from your mail system or provider
Microsoft 365 and other providers that use CNAMEs
Microsoft 365 and many sending services ask you to publish a CNAME at the selector that points to a key they host and rotate. In that case you do not publish a TXT key yourself. Use Inspect to check that the CNAME resolves to a valid key.
record & checks
dns output
one TXT record, split into strings where needed
DMARC record builder and validator
DMARC tells receivers what to do with mail whose From domain is not backed by an aligned SPF or DKIM pass, and where to send reports. It lives at _dmarc.domain. Move from none to quarantine to reject as the reports show your senders passing. RFC 7489 · RFC 9989
check an existing record
paste it, or fetch what is published
build
defaults are left out of the record
More options: failure-report options (fo=), np=
record & checks
dns output
copy into your DNS host
Live DNS inspector
Looks up what is published right now for the domain above using DNS-over-HTTPS, follows every SPF include to count lookups, checks DMARC report authorization and DKIM keys, and compares the results with what you built. Only the names being looked up are sent to the DNS provider you pick. RFC 8484
after publishing
a verification checklist
- Publish the record from the DNS output panel. Replace the old record at that name; do not add a second one.
- Check it here. Use Inspect, or "Check published" under any output panel, to confirm the published record matches what you built. If it still shows the old value, the answer is cached: wait out the TTL shown and check again.
- Send a test message to a mailbox at another provider and open its headers. The Authentication-Results line should show
spf=pass,dkim=passanddmarc=pass. - Watch the DMARC reports for a week or two before tightening the policy, and again after each change.
Help and references
spf, dkim and dmarc in short
SPF (Sender Policy Framework) is a TXT record at your domain that lists the servers allowed to send mail with your domain in the envelope sender (Return-Path). Receivers compare the connecting server's address with that list. Each include, a, mx, exists, ptr and redirect costs a DNS lookup, and the whole record, including everything it includes, may use at most 10. Over the limit, SPF fails for all your mail.
DKIM (DomainKeys Identified Mail) signs each message. Your mail system keeps the private key; the public key is published at selector._domainkey.yourdomain so receivers can check the signature. Use RSA keys of 2048 bits; long keys are published as several strings in one TXT record.
DMARC ties the two to the address people see. A message passes when SPF or DKIM passes for a domain aligned with the From address. The record at _dmarc.yourdomain tells receivers what to do with mail that fails (none, quarantine or reject) and where to send reports.
Troubleshooting usually comes down to one of these: two SPF records at one name, too many SPF lookups, a DKIM key split into two TXT records, a selector that does not match the one your signer uses, or a DMARC record whose first tag is not v=DMARC1. MailForge checks each of them.
one record, several strings
A DNS TXT string holds at most 255 bytes. Longer values, typically DKIM keys and long SPF records, are published as several strings inside one TXT record. Receivers join the strings back together with nothing in between (SPF §3.3, DKIM §3.6.2.2).
s1._domainkey TXT "…IDAQAB"
Two records break DKIM (neither half is a valid key) and, for SPF or DMARC, cause a permerror or no policy at all. In the Route 53 console, every line in the Value box is a separate record, so keep all strings on one line.
ttl guidance
- 3600 (one hour) is a sensible default for all three records.
- A day before a planned change, lower the TTL to 300 so a mistake can be undone quickly; raise it again once the new record checks out.
- When rotating DKIM keys, publish the new selector first, switch signing over, and keep the old key published for at least a week so mail already in transit still verifies.
what "valid" means here
MailForge checks syntax, limits and known pitfalls against the RFCs, and live DNS when you inspect. It cannot know whether the servers listed in SPF are really yours, whether your mail server signs with the private key matching the DKIM key, or how a particular receiver treats your mail. The test message in the after-publishing checklist is the final word.
Proposed repairs are only applied when you choose them. Each change is labeled: format same meaning, no effect removes something receivers never evaluate, merge combines address ranges covering exactly the same addresses, fix changes how receivers behave (for example a record they currently ignore). by hand items need your decision.
privacy
Building and checking happen in this page. Nothing is uploaded and there is no account, analytics or tracking. Your work is saved in this browser's local storage so it survives a reload.
Inspect, "Fetch published" and "Check published" are the only parts that use the network. They send the DNS names being looked up (such as _dmarc.example.com) to Cloudflare (cloudflare-dns.com) or Google (dns.google) over HTTPS, the same lookups any mail server would do. The records you type are never sent, and the page asks the browser not to send its address with those requests. Everything else works offline.
references
- RFC 7208: Sender Policy Framework (SPF). Lookup limits: §4.6.4.
- RFC 6376: DomainKeys Identified Mail (DKIM) signatures.
- RFC 8301: DKIM cryptographic update (no SHA-1, RSA ≥ 1024 bits).
- RFC 8463: Ed25519 for DKIM.
- RFC 7489: DMARC (2015). External report authorization: §7.1.
- RFC 9989: DMARC (May 2026), which replaced RFC 7489. It adds
t=,psd=andnp=and removespct=,rf=andri=. MailForge checks follow RFC 7489, which many receivers still implement, and say where RFC 9989 differs. - RFC 9990: DMARC aggregate reports. External report authorization: §4.
- RFC 1035 §3.3: TXT character-strings (255-byte limit).
- RFC 8484: DNS over HTTPS.
examples
- Domain that sends no mail: SPF
v=spf1 -all, DMARCv=DMARC1; p=reject, no DKIM. - Microsoft 365 only:
v=spf1 include:spf.protection.outlook.com -all, DKIM via the two Microsoft CNAMEs (selector1, selector2). - Starting DMARC:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain, then quarantine, then reject.