Greatmail SPF, DKIM and DMARC setup, step by step

On this page: Route · SPF · DKIM · Verification · FAQs · Mailbox migration boundary · DMARC policy · Troubleshooting · Further reading

To authenticate Greatmail email, use the DNS values supplied for your account, authorize the correct envelope domain with SPF, publish Greatmail's supplied DKIM TXT record, and verify a delivered message for DMARC alignment. Greatmail documents include:spf.greatmail.com, but an SMTP-only setup must not be confused with moving incoming mailboxes.

This is a documentary setup guide, not a report of customer-account access, DNS changes or delivery tests.

Choose the Greatmail route before changing DNS

Greatmail's own hosted email and its outbound SMTP service solve different problems. Its site also lists Rackspace Email and Exchange Hosting separately. Do not apply the native Greatmail DNS example to every product sold under the company name. Confirm the product on the order and in the account's setup instructions. Greatmail service and SMTP overview

Greatmail distinguishes Transactional and Marketing SMTP accounts; a split arrangement is support-coordinated. Its SMTP offering also provides an option to use a Greatmail return-path address for automatic DKIM signing. That is a convenience option, not documentary proof of alignment with your visible From domain. Inspect the actual identities, and ask support which custom-domain authentication configuration your route needs. SMTP hosting

Before editing anything, save the current zone, SPF policy, DKIM selectors, DMARC policy and mailbox routing. Inventory staff messages, billing, website forms, newsletters and support systems. Keep a route ledger containing the product, SMTP destination, visible From domain, observed envelope domain, expected signing domain and person responsible. This makes it possible to detect an application still using an old relay.

Configure Greatmail SPF

Greatmail's official single-provider example is:

v=spf1 mx include:spf.greatmail.com -all

This is a documented example, not an instruction to replace your existing record. The mx mechanism additionally authorizes hosts reached through your MX records. Confirm that breadth is intended, especially when incoming mail remains with another company. Do not authorize receiving servers as senders merely because they receive mail. Greatmail: Adding an SPF Record

If the account's setup confirms this authorization for your envelope domain, edit that domain's existing SPF TXT value to include include:spf.greatmail.com before its terminal all mechanism. Retain necessary authorizations for other services. If there is no record, build a complete policy from the approved sender inventory; the official example is suitable only when its assumptions match the actual route. For a Greatmail-owned envelope domain, adding an include at your own root does not change the authentication identity or make that SPF result align.

SPF checks the SMTP MAIL FROM domain (the envelope sender), not simply the visible From address. For an empty reverse path, SPF uses the HELO identity. A parent SPF record does not automatically authorize a subdomain. Identify the owner from the route and receiver evidence before editing DNS.

Publish only one SPF TXT policy at each owner. Merge authorized senders into that policy, preserve unrelated TXT records, and retain the existing terminal qualifier unless the domain owner separately approves a change. The limit is 10 evaluated DNS-query-causing terms, including nested includes and redirects, not ten visible services. Terms such as a, mx, include, exists and ptr consume the budget; ip4, ip6 and all do not. Evaluate the resulting policy, including nested dependencies, before publication. Do not replace a provider's managed include with a one-time snapshot of its IPs. RFC 7208

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

Publish the Greatmail DKIM record and confirm signing

Greatmail's hosted-email support instructions say the SPF and DKIM TXT settings are delivered in the signup setup email. Retrieve those original domain-specific instructions or request a current copy from support. The public page does not establish a universal selector, reusable public key or customer-side activation button. Greatmail hosted-email DNS instructions

1. Confirm the exact domain and service in those instructions. Ask for the expected DKIM signing domain, selector, full DNS owner, record type and complete public TXT value.
2. Publish the supplied public value at the authoritative DNS host. Do not copy a sample key, guess a selector or generate an unrelated key pair.
3. Query the resulting owner publicly and compare the full value with the supplied value. Keep private keys and SMTP credentials out of DNS.
4. Confirm with Greatmail that your domain's outbound signing is active for this route. Public documentation supports account-specific setup and assistance, but does not document a universal support toggle. Ask what remains outstanding rather than assuming a specific hidden workflow.
5. Send a new message from the intended From address and validate the receiver's signature and alignment results.

For SMTP-only service, support provides help with SPF and DKIM. Ask whether the quick-start provider return path also uses a provider signing domain. If so, an unrelated branded From domain needs a supported aligned authentication path before it can pass DMARC. Do not change From or weaken DMARC to conceal a mismatched setup. Greatmail SMTP setup scope

Keep mailbox migration separate from outbound authentication

An MX change reroutes incoming mail. Greatmail's hosted-mailbox setup requires the supplied receiving configuration; configuring outbound-only SMTP does not authorize changing your main-domain MX. If you are actually migrating mailboxes, provision and test the destination, preserve access to the old host during transition, and validate receiving, replies and sending independently. Greatmail hosted-email setup

Only for an authorized hosted-mailbox migration, obtain the mail-routing owner’s separate approval of the complete MX design before publication or activation: every full owner, numeric priority and destination hostname. Receiving Greatmail’s setup packet alone is not approval of that routing change. Reconcile the complete proposed set with the authorized incoming-mail plan, then compare the entire approved set at the authoritative servers and a public recursive resolver. Stop on any unexpected or conflicting tuple; one matching target is not sufficient. Preserve existing receiving access and unrelated routing until the approved cutover plan permits the change. This gate does not make MX changes part of outbound-only SMTP authentication.

A lost inbound message after an MX change is not fixed by regenerating DKIM. Conversely, working incoming mail says nothing about an application's outbound signature. Keep a record of the previous MX and routing decisions so an approved recovery can restore the affected service without erasing working authentication.

Preserve or establish the applicable DMARC policy

DMARC succeeds when either SPF passes with an aligned envelope domain or DKIM passes with an aligned signing domain. Under relaxed alignment, the authenticated and visible From domains share an organizational domain; under strict aspf=s or adkim=s, they must match exactly. Reply-To, SMTP login and a link-tracking hostname are not substitutes for these identifiers. Current DMARC standard, RFC 9989

Before adding a record, inspect the visible From domain's DMARC policy and any applicable inherited policy. Preserve existing enforcement, alignment and reporting choices. Do not add a child p=none record merely to escape a parent's quarantine or reject policy.

Only if there is no established applicable DMARC policy, and the domain owner approves a monitored first deployment, create one TXT record at _dmarc.example.com for a From domain of example.com. For newsletter.example.com, the corresponding owner is _dmarc.newsletter.example.com. These are examples, not your account's names. After creating and approving a real reporting mailbox, a monitoring example is:

v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

For a DNS editor opened on the example.com zone, the relative owner is _dmarc for the apex policy or _dmarc.newsletter for newsletter.example.com. If the editor is opened directly on the newsletter.example.com child zone, use _dmarc there. Confirm the resulting fully qualified name. Replace the reporting address with the approved destination. Check that it accepts reports and that your team can process them. A destination on another domain can require external-report authorization by that destination's DNS administrator. Do not substitute a vendor's reporting address without agreement about the data it receives. Aggregate reporting and external-destination authorization, RFC 9990 §4

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Monitoring does not request quarantine or rejection of spoofed mail, and does not guarantee delivery. Assess every legitimate sender, including low-frequency billing and automated systems, before the owner approves stronger enforcement. Do not use the obsolete pct tag as a current percentage-rollout control. Failure reports are a separate, potentially sensitive data flow: omit ruf unless there is an approved need and privacy review. RFC 9989, Failure reporting, RFC 9991

Verify public DNS and a delivered message separately

Replace every example name below with the actual envelope domain, signing domain, selector and visible From domain. These commands read DNS; they do not activate signing or send mail.

dig +short NS example.com
dig +short TXT example.com
dig +short TXT selector._domainkey.example.com
dig +short CNAME selector._domainkey.example.com
dig +short TXT _dmarc.example.com

Check the authoritative server as well as a public recursive resolver. For example, replace ns1.example.net with a real authoritative nameserver and use dig @ns1.example.net TXT example.com. Compare with dig @1.1.1.1 TXT example.com. For a delegated subdomain, query its actual authority. Wait for relevant positive and negative cache lifetimes, then recheck discrepancies.

Acceptance requires one valid SPF policy at the envelope owner, the exact supplied DKIM public record at the message's selector owner, and the intended DMARC policy. TXT data may be divided into multiple quoted character strings within one record; that is different from publishing competing SPF records. DNS editors may append the zone automatically: check that a full owner did not become selector._domainkey.example.com.example.com. A CNAME cannot coexist with other ordinary record data at the same owner. Resolve a conflict with the administrator rather than deleting an unrelated record.

For an issued signing domain such as news.example.com, the illustrative full owner is ISSUED-SELECTOR._domainkey.news.example.com. In an editor relative to the parent example.com zone use ISSUED-SELECTOR._domainkey.news; in a separately delegated news.example.com zone use ISSUED-SELECTOR._domainkey; in a delegated _domainkey.news.example.com zone use only ISSUED-SELECTOR. Replace the placeholder with the issued selector and preserve the exact account type and value. These mappings do not establish product eligibility for a new domain. Publish at the actual authority, preserve NS delegation and check the resulting full owner. DKIM owner construction, relative DNS names.

Next, send a fresh representative message through the actual production route to an independent mailbox you control. Open its raw source and use the Authentication-Results added by the trusted receiving system, not arbitrary header text supplied by a sender. RFC 8601

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Record the visible From domain, smtp.mailfrom, DKIM header.d and signature s=, plus the receiver's SPF, DKIM and DMARC results. A useful acceptance result is dmarc=pass with an identified aligned passing branch. Prefer to establish both SPF and DKIM authentication where the route supports them; DMARC itself only needs one aligned pass. A provider-domain SPF pass with no aligned DKIM does not prove your brand domain authenticated.

Accept this branded-DKIM setup only when the intended provider signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. SPF-only DMARC success does not complete the DKIM deployment. Independently diagnose SPF fail or softfail (authorization mismatch), temperror (transient evaluation failure, often DNS) and permerror (uninterpretable policy, duplicates or lookup limits) at the observed smtp.mailfrom, even when aligned DKIM supplies DMARC. A passing but unaligned provider envelope is a different outcome from an SPF error. DMARC alignment, SPF results.

Repeat for each real sender path, including aliases, applications and forwarded mail where relevant. Inspect delivery or bounce evidence separately: an authentication pass cannot guarantee inbox placement, and a successful SMTP submission only proves the server accepted the submission. Preserve redacted headers and timestamps for troubleshooting, without uploading private message content to a public analyzer.

Troubleshoot Greatmail authentication by symptom

Further reading

Start with Greatmail's SPF example, hosted-email DNS instructions and SMTP product documentation. The standard references above explain why account verification, DNS publication and real-message alignment are separate checks.

If ordinary corporate mail remains with Microsoft 365 while Greatmail carries application traffic, keep those authorizations separate and review Microsoft 365 authentication for that other route.