Deliverability
SPF, DKIM and DMARC for an outreach workspace
What each DNS record is for, the exact shapes MAILTIG generates, and why a green check is not inbox placement.
By MAILTIG editorial. Reviewed by Engineering (Deliverability engineer (product source)) on 4 November 2026. Next review due 4 February 2027. 8 minute read.
A sending domain is the domain in the From address. MAILTIG asks you to prove you control it before a campaign can start. That proof is four TXT records.
The four records MAILTIG generates
| Purpose | Host | Example value |
|---|---|---|
| Verification | the domain itself | mailtig-verify={token} |
| SPF | the domain itself | v=spf1 include:_spf.google.com ~all |
| DKIM | {selector}._domainkey.{domain} | v=DKIM1; k=rsa; p=… |
| DMARC | _dmarc.{domain} | v=DMARC1; p=none; |
These shapes come from MAILTIG's SendingDomainRecordBuilder. The SPF include of _spf.google.com is the default MAILTIG writes; if you send through Microsoft or an ESP you must replace that include with the provider your mailbox actually uses. Publishing the generated record unchanged against the wrong provider is a common failure.
What each record proves
- SPF lists which hosts may send mail that claims this domain in the envelope. It does not sign the message body.
- DKIM attaches a signature to the message. MAILTIG signs SMTP sends with the domain's key once the DKIM check has passed. Gmail, Microsoft 365 and ESP sends are signed by those providers.
- DMARC tells a receiver what to do when SPF and DKIM do not align. MAILTIG's generated policy is
p=none: observe, do not reject. Tightening that policy is your decision, after you have seen reports.
What a green check does not prove
MAILTIG looks the records up and marks Pass or Fail. All four must pass for the domain to become Verified. That is necessary. It is not sufficient for inbox placement. Receivers still weigh reputation, content, volume and complaints. See Why delivery is not inbox placement.