For AWeber's standard email-marketing route, verify your From address, configure the DKIM CNAME records shown in Domains and Addresses, and preserve your domain's DMARC policy. AWeber says you do not need to update your customer-domain SPF record for this route. Finish by confirming that the correct list uses the authenticated address and that a real delivered message has aligned DKIM and DMARC pass.
On this page
- Separate the address, domain and list
- Does AWeber need an SPF include?
- Set up DKIM in AWeber
- Preserve DMARC and reporting
- Verify public DNS and delivered mail
- Troubleshoot before the next broadcast
- Frequently asked questions
Separate the address, domain and list
There are three different checks: control of an email address, authentication of its domain, and selection of that address for the intended list. Passing one does not prove the others. A verification email demonstrates access to a mailbox; it does not publish DKIM. Installed DNS records do not prove that your next broadcast selects the intended From address.
AWeber's current address instructions put the sender under List Options → List Settings → Basic Settings. Add the address through the From Address control, request verification and complete the email confirmation. The provider documents one active From address per list and identifies Plus for multiple lists. Confirm your actual account's available plan and list controls before planning a multi-identity rollout. AWeber From-address setup.
Use a real monitored mailbox on a domain your organization owns. You cannot configure DNS authentication for another organization's public mailbox domain. Keep the From address, reply mailbox and bounce identity distinct in your change record; they perform different functions even when their names look related.
This guide addresses AWeber's own sending service. It does not authenticate mail sent directly by your employee mailbox provider. If that route is Microsoft 365, use EmailAuth's Microsoft 365 authentication guide separately. Preserve its DNS records while adding AWeber.
Before setup, identify the AWeber account, list, exact From domain and authoritative DNS host. Export existing SPF, DKIM and DMARC entries, note TTLs, and agree who approves changes. Include scheduled broadcasts in the inventory so the configuration is not changed without the campaign owner knowing.
Does AWeber need an SPF include?
Not for the documented standard route. AWeber's current SPF article explains that the envelope/return-path domain normally belongs to the service. Adding AWeber to the visible From domain's SPF policy does not change that identity. The page still shows an optional legacy-style include example, but its main instruction is that a customer-domain SPF update is unnecessary. AWeber's SPF explanation.
Do not confuse SPF authentication with DMARC alignment. A receiving server can report spf=pass for an AWeber-owned envelope domain while that identity does not align with your visible From. Aligned DKIM can still make DMARC pass. A root-domain SPF checker cannot establish the authentication result of a message whose MAIL FROM uses a different domain.
Keep existing SPF records used by your mailbox and application senders. This is not a recommendation to delete SPF altogether. If you discover an old AWeber include, review why it was added and who relies on the policy before removing it; cleanup is a separate controlled change.
For any SPF owner, publish at most one SPF policy. Preserve legitimate senders and the existing terminal policy when making an authorized edit. The limit of ten DNS-querying terms applies during evaluation, including nested includes. Do not add a second v=spf1 record or unnecessary includes to make a dashboard look complete. SPF standard.
Set up DKIM in AWeber
AWeber requires the address to be added and verified first. In Domains and Addresses, use the domain's gear/setup control to view its records. The manual documentation currently lists three DKIM CNAMEs; copy the names and targets from your account. After publication, inspect the domain's record status for Installed. Current DKIM and DMARC workflow.
Publish all issued DKIM records, not only one selector. Keep the account's complete owner and target together in a worksheet with record type and date. A target is a DNS hostname, not an email address, URL or public-key text. Do not generate your own key or paste private key material into DNS.
The same guide offers automatic domain connection for supported DNS providers. Automatic setup configures DKIM and DMARC together, so review the access requested and the policy changes before approving it. Manual publication is preferable when a shared zone or an established security policy requires a controlled change review. Automatic and manual options.
Check which DNS zone the editor actually manages. If the complete owner is SELECTOR._domainkey.news.example.com and the editor appends example.com, the relative owner is SELECTOR._domainkey.news. If it manages a separately delegated news.example.com zone, the relative owner is SELECTOR._domainkey. These are placeholders, not AWeber-issued values.
Before saving, look for an existing record at each owner. A CNAME ordinarily cannot coexist with other ordinary data at the same name. Do not overwrite a selector used by another service or copy a CNAME destination into a TXT field. Keep web-proxy features disabled for authentication aliases so DNS returns the intended destination. DNS alias rules.
Where the actual authoritative DNS host offers these controls, use DNS-only aliases, not HTTP proxying or redirects, and keep a literal CNAME answer to each required target. Turn the relevant per-record Flatten option off when available, and ensure applicable zone-wide settings do not conceal the issued aliases. For Cloudflare specifically, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are Cloudflare behaviors, not assumed controls in another provider’s panel. If mandatory behavior or shared settings prevent the required CNAME answer, stop and coordinate a supported configuration without breaking dependent records. Do not blindly change the whole zone or remove an NS delegation; publish at the delegated authority when appropriate. Cloudflare CNAME verification, flattening controls.
Preserve DMARC and reporting
Read the existing policy before following a setup suggestion. Check the exact From domain and any policy inherited from a parent. Preserve established enforcement, alignment modes and authorized reporting destinations. An absent subdomain record can mean inheritance, not absence of protection. Adding p=none there may weaken the existing policy.
AWeber's documentation includes a minimal DMARC example with a vendor reporting destination and the older pct tag. Do not copy that example over an established policy or direct reports to a new organization without approval. The current DMARC specification is RFC 9989, which supersedes RFC 7489 and removes pct. Current DMARC standard.
DMARC requires at least one passing, aligned identity from SPF or DKIM. Relaxed alignment compares organizational domains; strict alignment requires exact equality. For AWeber, confirm that the passing DKIM d= aligns with your From domain under the existing adkim setting. A valid signature for an unrelated domain cannot satisfy that requirement.
If no effective DMARC policy exists, a monitored p=none introduction can be approved by the domain owner. Select an authorized report destination and assign someone to review results. Do not add multiple DMARC TXT policies at one owner. If duplicates already exist, reconcile their intended settings with the domain owner instead of simply keeping whichever permissive example a tutorial provides.
For an owner-approved first monitoring policy only, with no direct or applicable inherited policy to preserve, publish one TXT policy at the actual From domain’s DMARC owner. From example.com uses full owner _dmarc.example.com, or _dmarc relative to the example.com zone. From news.example.com uses full owner _dmarc.news.example.com: enter _dmarc.news in the parent zone, but _dmarc in a separately delegated news.example.com zone. Publish at the actual authority and preserve NS delegation; never create a child monitoring override of existing protection. DMARC policy publication, relative DNS names. An illustrative first-policy value is v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com. Replace the example with an approved functioning mailbox, not AWeber’s sample recipient. 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.
Treat a policy change as a separate decision from publishing AWeber's keys. A failed campaign is a reason to investigate its identity and records, not automatic justification to lower protection across all your organization's mail.
Verify public DNS and delivered mail
Use read-only DNS checks before sending. Replace every placeholder below with the exact owner or authoritative server for your domain:
dig +short NS example.com
dig @ns1.example.net SELECTOR._domainkey.example.com CNAME
dig @1.1.1.1 SELECTOR._domainkey.example.com CNAME
dig @1.1.1.1 SELECTOR._domainkey.example.com TXT
dig @1.1.1.1 _dmarc.example.com TXT
Repeat for all issued selectors. The authoritative answer should show the correct CNAME; a public recursive lookup should resolve the expected chain and public key. Compare published values with the account, not with a screenshot in an old guide. A correct CNAME label pointing to the wrong target is still wrong.
Check effective DMARC policy separately. For SPF, query the MAIL FROM domain observed in a delivered message, rather than assuming the customer root is evaluated. Save full DNS responses if a command returns no useful answer; NXDOMAIN, timeout and SERVFAIL are not interchangeable diagnoses.
AWeber allows up to 48 hours for DNS changes and status updates to appear. Recheck after relevant caches expire, but investigate an incorrect authoritative answer immediately rather than waiting out that entire window. Official propagation allowance.
Return to AWeber and confirm Installed status, then review the list's active From address. AWeber documents that it checks authentication at broadcast send time and returns the broadcast to Draft if the domain is no longer authenticated. A previous successful setup therefore does not eliminate the need to retain the records. AWeber send-time check.
With authorization, send a controlled broadcast to external recipients and inspect original headers. Also test a representative automation if your rollout includes one. Do not assume an editor preview proves the production route.
Record the visible From, Return-Path, DKIM d= and s=, and the receiving system's Authentication-Results. Trust results added by the receiving mailbox infrastructure, not arbitrary sender-supplied header fields. Authentication-Results trust model.
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.
The acceptance criteria are: correct public records, provider installation status, the intended list sender, a valid aligned DKIM signature, and dmarc=pass at the receiver. SPF can pass for AWeber without aligning. Merely resolving a public key cannot prove signature verification. DKIM specification.
Keep dated, sanitized header evidence. Authentication does not guarantee inbox placement.
Troubleshoot before the next broadcast
The address needs authentication although the domain looks installed: Check whether address verification was completed and whether the list selected the verified address. Separate a mailbox-verification problem from a DNS problem.
Only some DKIM records resolve: Compare all issued selectors and targets. Do not stop after one lookup succeeds. A missing alternate record can be overlooked when testing only the selector used by one message.
The broadcast returns to Draft: Check the current domain status and the notification, then inspect public DNS for deletion, host migration or accidental edits. Re-authenticate and retest before rescheduling; do not assume retrying alone fixes it.
SPF passes but a tool calls it unaligned: Compare MAIL FROM and From. If aligned DKIM and DMARC pass, that observation is consistent with the documented route. Adding root SPF authorizations does not change the envelope sender.
SPF actually fails: Investigate the receiver's SPF result and the evaluated MAIL FROM domain independently, even if aligned DKIM makes DMARC pass. Preserve the result and sending IP, inspect that domain's published policy, and escalate unexpected provider-domain failures to AWeber. A real fail, permerror or temperror is not the same as passing SPF without alignment.
DKIM passes but DMARC fails: Check which signature passed and whether its d= matches the actual From domain under strict or relaxed policy. Also compare direct delivery with forwarded mail if an intermediate system changed the message.
Nothing changes after waiting: Verify authoritative nameservers, owner suffixes and record types. Caches can delay correct changes, but time cannot repair a record published in the wrong zone. Escalate with sanitized account status, exact public records and a representative message, never DNS credentials or private keys.