In eMarketeer, an administrator opens Account Settings > Email Domains, adds the sending domain, publishes its issued authentication records and selects Authenticate. The current official setup shows three managed DKIM CNAMEs and a mandatory SPF TXT policy; successful checks turn green and the domain becomes Authenticated. Use your own account packet, not the screenshot's selectors or domain. Current domain setup.
This guide completes the documented core SPF/DKIM authorization workflow. It deliberately leaves optional custom MAIL FROM routing unconfigured until the account or eMarketeer support supplies a complete approved routing and fallback design. That boundary matters because the public screenshot shows an MX target but not its numeric priority.
Confirm scope, access and the current packet
An authorized email domain is required before eMarketeer permits outgoing email. The troubleshooting documentation requires administrator privileges for Email Domain settings. Arrange separate authorized DNS access and identify the campaign owner who approves the intended visible From domain. Do not confuse this task with a custom website/link hostname, mailbox migration or an independently operated Amazon SES account. DKIM administration.
Save the existing domain's SPF policy, DKIM selectors, direct and inherited DMARC settings, DNS delegation and any bounce routing. Record the intended account, campaigns and sender addresses. New account credentials, broader access or sending to real customers are not implicit parts of DNS configuration.
No universal plan or geographical region is established by the reviewed setup. The screenshot's SES targets and example domain demonstrate a record shape, not permission to substitute its region, selector or customer identifier into your configuration.
Add the email domain and obtain its records
- In eMarketeer, select the gear icon and open Account Settings.
- Open Email Domains and select Add A Domain.
- Enter the domain intended for the From address and select Add.
- The domain appears as Pending, and Authenticate Domain opens with its DNS instructions.
- Copy every relevant full owner, record type and value from your own packet. Keep the domain and account beside the copied records.
The official dialog groups DKIM (mandatory), SPF (mandatory), DMARC and MAIL FROM separately. Its Click here to generate an email option prepares the records in the user's email program. It is an optional handoff aid, not permission to send data to an unapproved recipient. Have the DNS owner review the packet before publication. Issuance and status workflow.
Publish all three issued DKIM CNAMEs
The current official failing and passing dialog screenshots show three CNAME records, each mapping an account-issued selector owner to its corresponding managed DKIM target. Copy all three exact pairs. Do not create a generic default selector, generate unrelated keys or upload a private signing key based on an old tutorial.
Translate the actual full owner for the authoritative zone. If an issued owner were SELECTOR._domainkey.news.example.com, the relative input would be SELECTOR._domainkey.news in example.com, SELECTOR._domainkey in a delegated news.example.com zone, or SELECTOR at an existing delegated _domainkey.news.example.com authority. These are naming examples, not eMarketeer selector values. Preserve NS delegation and other senders' selectors. DNS relative names.
A CNAME owner cannot also contain ordinary TXT, A, AAAA, MX or a second conflicting alias. If an issued name collides with a working service, stop and coordinate a supported allocation rather than deleting that service. These DKIM aliases are not website traffic: use DNS-only, not an HTTP proxy, where your DNS host offers proxying.
Preserve a literal CNAME answer at each issued owner. If a relevant per-record Flatten control exists, turn it off for that authentication alias. Ensure applicable whole-zone settings do not conceal the aliases, without blindly changing shared settings. Mandatory apex or same-zone flattening can still matter: if the host cannot preserve the required literal answer, stop and coordinate a supported configuration with the DNS owner and provider. Do not invent a switch or remove delegation. Cloudflare documents per-record, whole-zone and same-zone behavior; other hosts have different controls. Cloudflare CNAME flattening, configuration.
Query every issued alias at authoritative and recursive DNS and follow its target to a usable public DKIM key. An exact alias without a resolvable key is not enough. For example, replace every placeholder before these read-only checks:
dig @AUTHORITATIVE-NS CNAME ISSUED-SELECTOR-OWNER +noall +answer
dig @1.1.1.1 CNAME ISSUED-SELECTOR-OWNER +noall +answer
dig @1.1.1.1 TXT ISSUED-DKIM-TARGET +noall +answer
Repeat for all three pairs, not just the first. Keep the full public values intact and the private signing material with the provider. DKIM key resolution.
Reconcile SPF rather than copying a conflicting example
The official setup screenshot displays include:spf1.emarketeer.com and a neutral ?all ending. However, the separate current SPF troubleshooting page labels include:spf.emarketeer.com ~all a generic example. That discrepancy is real. Do not choose one as a universal literal, add both just in case or silently replace your qualifier.
Use the complete SPF instruction displayed for the actual account/domain, reconcile it with existing legitimate senders, and ask eMarketeer to resolve any mismatch between the account packet and documentation before publishing. The troubleshooting path is Email Domain settings > Check authentication, which displays the required records. A neutral ?all does not mean hardfail, and a provider example does not authorize a different enforcement policy. Official SPF troubleshooting.
Preserve one SPF TXT policy at the specified owner. The safe merging, lookup-budget and redirect rules below apply even when the application presents a standalone policy. Do not migrate incoming mailbox MX or website records to satisfy SPF.
Map each actual issued SPF owner explicitly: full example.com uses relative @ (or the host’s documented apex input) in its zone; full news.example.com uses news in the parent zone or @ at a delegated news.example.com authority. An apex-domain DKIM owner SELECTOR._domainkey.example.com uses SELECTOR._domainkey in the parent zone or SELECTOR at an existing delegated _domainkey.example.com authority. Use the actual issued selector and preserve NS delegation; these examples do not assign an envelope or selector to your account. Owner mapping.
Keep optional custom MAIL FROM routing on hold
The public setup screenshot includes a MAIL FROM child-domain SPF TXT and an MX target, alongside the mandatory core records. It does not show the MX numeric priority or establish the application's fallback behavior when this routing fails. Its example feedback child and SES region must not become universal instructions.
Before configuring that optional branch, obtain a complete account-specific packet from eMarketeer, including full owners, TXT policy, MX numeric priority and target, activation/verification steps and fallback behavior. The sending/routing owner must separately approve that complete design; receipt of a packet is not approval to redirect bounces. Use an appropriate dedicated child, preserve corporate mailbox routing and existing dependencies, and compare the complete approved record set at authoritative and recursive DNS before activation. Stop on any mismatch or missing priority.
Until that work is complete, leave custom MAIL FROM unconfigured and make no claim that SPF aligns, especially under strict aspf=s. Even a correctly configured child envelope generally supplies only relaxed alignment with a parent From unless the identities exactly match. For the core workflow, establish aligned DKIM and inspect the actual envelope independently; do not invent a default envelope domain. The EmailAuth custom MAIL FROM guide explains the distinct routing and identity acceptance checks.
Authenticate and verify the provider state
After safe core DNS publication, reopen Authenticate Domain and choose Authenticate. The current official instructions say correct records get green checks and the domain status becomes Authenticated. A failing record retains its red cross. If eMarketeer cannot verify within 72 hours, the domain shows Failed; use Restart Validation after correcting the actual cause. Its stated 48-hour propagation allowance is not a guarantee. Complete validation procedure.
For later problems, use Check authentication to compare the required packet with current DNS. No additional separate signing-enable switch is established in these instructions. If the account will not authenticate the safe core configuration without a changed DMARC policy or incomplete optional routing, stop for provider clarification. Do not downgrade policy or invent routing just to make a status green.
Preserve SPF and DMARC policy
SPF evaluates the actual SMTP MAIL FROM identity, not automatically the visible From address. A provider's domain-authorization instruction does not prove which envelope domain a delivered message uses. Inspect that identity separately; do not promise SPF alignment or invent a custom return path. EmailAuth's custom MAIL FROM and alignment guide explains why publication, routing and actual message identity are different checks.
Keep one v=spf1 TXT policy at each evaluated owner. Merge only the approved provider authorization into an existing policy before its terminal all; retain other legitimate senders and the approved qualifier. Count the ten evaluated DNS-dependent terms across includes and redirects, not merely ten top-level includes. If a policy uses redirect=, do not blindly add all: an all mechanism makes the redirect ignored. Review the complete resulting authorization instead. Do not freeze changing provider IPs into a static SPF record as a shortcut. SPF processing, redirect.
Look up the direct and applicable inherited DMARC policy for the intended visible From domain. Preserve its enforcement, alignment settings and approved report recipients. Do not replace a working policy with a provider's p=none example, duplicate DMARC, or create a child monitoring override that weakens inherited protection.
Only if no direct or applicable inherited policy exists and the domain owner approves a monitoring and review plan, an illustrative first record is TXT with value v=DMARC1; p=none. From example.com uses full owner _dmarc.example.com, relative _dmarc in its zone. From news.example.com uses _dmarc.news.example.com: relative _dmarc.news in the parent zone, but _dmarc at a separately delegated news.example.com authority. Preserve that delegation. This value requests no reports by itself. DMARC publication.
Add rua only for a provisioned, approved and monitored recipient. Compare the Organizational Domain of the report URI's host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily visible From. If they differ, the report-generating receiver must check external-report DNS authorization; a destination within the same Organizational Domain as the policy domain is excepted. A different hostname alone is not sufficient. This check does not replace the owner's approval to share report data. RFC 9990 section 4.
DMARC can pass through either aligned SPF or aligned DKIM. Relaxed alignment compares Organizational Domains; strict adkim=s requires the signing domain to match the From domain exactly. Check the effective policy, not just a green dashboard. RFC 9989 replaces RFC 7489 and removes pct; do not design a new rollout around that obsolete tag. For domains publishing p=reject, retain the valid-DKIM requirement and consider indirect/list interoperability before changing policy. Alignment, indirect flows.
Prove publication and actual signing separately
Use read-only queries with the actual authority and account-issued names in place of these uppercase placeholders:
dig +short NS YOUR-ZONE
dig @AUTHORITATIVE-NS TXT YOUR-SPF-OWNER +noall +answer
dig @AUTHORITATIVE-NS CNAME YOUR-ISSUED-DKIM-OWNER +noall +answer
dig @1.1.1.1 CNAME YOUR-ISSUED-DKIM-OWNER +noall +answer
dig @TARGET-AUTHORITATIVE-NS TXT YOUR-RESOLVED-DKIM-TARGET +noall +answer
dig @1.1.1.1 TXT YOUR-RESOLVED-DKIM-TARGET +noall +answer
dig @1.1.1.1 TXT _dmarc.YOUR-FROM-DOMAIN +noall +answer
Repeat both stages for all three issued DKIM CNAMEs: verify the literal alias at its owner, then resolve its target to the expected public-key TXT answer using that target zone’s authority and a recursive resolver. Resolve any discrepancy between authoritative and recursive answers before claiming completion. A successful DNS lookup is not a delivered-message test. Save the full owner, type, value, timestamp and provider status without publishing private credentials.
Have an authorized operator send new representative messages through the intended application or campaign path to controlled external recipients. Use synthetic records and approved harmless content, not real customer notifications. Capture the unchanged intended visible From, actual MAIL FROM/Return-Path, DKIM d= and s=, route and time.
Establish which Authentication-Results fields the actual receiving service generated inside its known processing boundary and how it removes, ignores or distinguishes externally supplied fields. Use documented receiver handling or an administrator-verified trace if unclear. Header position or a familiar authserv-id string alone is not proof. Ignore injected or otherwise untrusted results. Receiver trust boundary.
For branded-DKIM acceptance, match the intended provider's active issued d= and s= to the tested route. Require that signature to pass and align under effective adkim with the unchanged intended visible From, plus trusted receiver dmarc=pass. Another aligned signer, rewritten provider From or SPF-only DMARC pass does not complete this DKIM deployment.
Diagnose SPF separately at the actual smtp.mailfrom domain: fail or softfail calls for checking the connecting sender against approved authorization; temperror is a transient evaluation problem, often DNS; permerror calls for checking malformed or duplicate policies and the evaluated lookup budget. Aligned DKIM does not repair an SPF fault. Do not edit an unrelated apex policy to fix a provider-controlled envelope domain. SPF results.
Troubleshooting and controlled recovery
- DKIM checks stay red: Compare all three full owners and targets, authority, suffix duplication, conflicting records and hidden/flattened aliases. Resolve each target's public key.
- SPF instructions disagree: Preserve the current policy and confirm the correct account instruction with eMarketeer. Do not append both published example includes without a supported reason.
- Authenticated but branded DMARC fails: Check the actual intended eMarketeer signature and unchanged From. A different campaign sender or strict alignment choice can differ from the domain you configured.
- Optional MAIL FROM remains incomplete: Keep it unconfigured until the complete approved packet and fallback procedure exist. A guessed MX priority is not an acceptable workaround.
- The account reports Failed: Correct the underlying DNS issue, then Restart Validation. Repeatedly clicking it does not fix a wrong owner, missing key or conflict.
- Authentication passes but campaigns underperform: Review consent, unsubscribe functionality, complaints, content, volume and warm-up with the campaign owner. DNS status is not inbox-placement proof.
Retain the original configuration and received-message evidence. With the campaign and DNS owners' approval, pause only affected sending or restore the prior approved configuration after a regression. Do not delete managed selectors still needed by queued mail or rotation. Retest the failed path and a known-good control with harmless controlled recipients; do not deliberately break live bounce routing to discover fallback behavior.
Documentation and testing boundary
The complete current official setup and SPF/DKIM/DMARC troubleshooting bodies were read, and both failing and passing record-dialog screenshots were inspected. Account-specific screenshot tokens were not reused. No account, DNS, credentials, campaign or sending configuration was changed and no message was sent. Optional MAIL FROM remains a separate unresolved account-routing task, not a verified deployment.