Why all three exist
Email was designed in an era of implicit trust, so the 'From' address is trivial to forge. SPF, DKIM, and DMARC are the layered fix. SPF says which servers may send for your domain. DKIM proves a message was not tampered with and genuinely originated from your domain. DMARC ties the first two to the visible From address and tells receivers what to do when a check fails.
Since the Google and Yahoo bulk-sender requirements of February 2024 — and Microsoft's matching rules for consumer Outlook domains rolling out through 2025 — publishing all three is a hard requirement for anyone sending meaningful volume. Miss one and your mail is filtered or refused.
SPF: who is allowed to send
SPF (Sender Policy Framework) is a single TXT record on your domain that lists the mail servers permitted to send on its behalf. A receiving server checks the envelope sender against this list. For a domain sending through Google Workspace, the record looks like this:
v=spf1 include:_spf.google.com ~allThe include pulls in Google's authorized servers, and ~all is a soft-fail that tells receivers to treat anything else as suspicious. Two rules trip people up: you may only have one SPF record per domain, and it must stay within a limit of ten DNS lookups. Stacking multiple sending tools by adding more includes is the usual way people silently break SPF.
DKIM: proof the message is untouched
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message using a private key held by your sending platform. The matching public key is published as a TXT record at a selector on your domain, so any receiver can verify the signature. A Google Workspace DKIM record is published at a selector such as google._domainkey and looks like this:
google._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFA..."If the signature validates, the receiver knows the message body and key headers were not altered in transit and that the domain owner authorized it. DKIM is generated after your mailboxes exist, which is why it is the last authentication record to go live in an automated setup — the signing keys are created with the Workspace mailboxes and then published.
DMARC: the policy that ties it together
DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a TXT record at _dmarc on your domain. It requires that SPF or DKIM not only pass but align with the visible From domain, and it states a policy for handling failures plus an address for aggregate reports. A monitoring-stage record looks like this:
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com"The p value is the instruction to receivers. p=none means 'do nothing, just report,' p=quarantine means 'send failures to spam,' and p=reject means 'refuse them outright.' The rua address collects the daily aggregate reports that show you who is sending as your domain and whether they pass.
The p=none to p=reject journey
You do not publish p=reject on day one — that risks silently dropping your own legitimate mail if any source is misconfigured. Instead you walk the policy up in three stages. Start at p=none and read the aggregate reports for a couple of weeks until you can see every legitimate sender passing SPF or DKIM with alignment. Then move to p=quarantine, optionally with a pct tag to apply it to a fraction of mail first, and confirm nothing legitimate is being filtered. Finally move to p=reject, at which point spoofed mail using your domain is refused before delivery.
Reaching p=reject is the strongest signal of a well-run domain and the endpoint the bulk-sender rules are steering everyone toward. The whole journey is safe precisely because it starts in a monitor-only mode that cannot hurt your delivery.
Getting it right without touching a DNS console
None of this is conceptually hard, but the failure modes are unforgiving: one malformed record, a second SPF entry, or a DKIM key that never got published, and your campaign quietly lands in spam. This is exactly the work GoodInboxes automates — SPF, DMARC, and MX are verified before an inbox goes live, and DKIM signing is added automatically once the Workspace mailboxes are created, so you never copy a TXT record into a registrar. Once the records are in place, warmup does the rest; see how email warmup actually works and why 30 days for the other half of a deliverable setup.