How to Set Up SPF, DKIM and DMARC for AWeber (2026)

AWeber is an email marketing platform used by small businesses, creators, and agencies to send newsletters and automated campaigns. Because AWeber sends on behalf of your domain, misconfigured authentication means your mail can land in spam or get rejected outright. Follow the steps below and you will have SPF, DKIM, and DMARC records published, tested, and passing.

Before you begin

• DNS write access to your domain at your registrar or DNS host (Cloudflare, Route 53, GoDaddy, etc.)
• Admin-level access to your AWeber account
• A verified sending domain inside AWeber (AWeber must already recognise the domain you are authenticating)
• The ability to send a test email from that domain and view full message headers
• A clear picture of every other service sending mail from your domain — you will need to merge their SPF includes into a single record

Step 1: Identify what is sending from AWeber

AWeber routes outbound mail through its own sending infrastructure, which can span multiple IP ranges, shared relay pools, and — depending on your account tier — dedicated IP addresses. Before you touch DNS, log in to your AWeber account and check whether you have a dedicated IP or a shared pool assigned to your account. This affects which IP ranges the SPF record must authorise. AWeber may also inject its own Return-Path domain, so confirm whether you are using a custom return-path (your own domain) or AWeber's default return-path before finalising your SPF and DMARC alignment strategy.

Step 2: Add the SPF include

AWeber's outbound mail servers must be listed in the SPF record for your sending domain. AWeber publishes a dedicated SPF include mechanism for this purpose. Log in to your AWeber account, navigate to the email authentication or domain settings section, and confirm the exact include: string shown there — do not rely on any value printed in third-party guides (including this one) because vendors update their infrastructure.

The general form of your SPF record should look like this:

; BEFORE — SPF with no AWeber authorisation
your-domain.com.  IN  TXT  "v=spf1 include:_spf.google.com ~all"

; AFTER — AWeber include merged in
your-domain.com.  IN  TXT  "v=spf1 include:_spf.google.com include:<aweber-spf-include> ~all"

Replace <aweber-spf-include> with the exact value from AWeber's DNS setup documentation or your account's domain authentication screen.

SPF lookup limit warning: The SPF specification enforces a hard limit of 10 DNS lookups per evaluation. Each include:, a:, and mx: mechanism that triggers a DNS query counts toward that limit. AWeber's own include may itself chain into additional lookups. If you also send through Google Workspace, Microsoft 365, Salesforce, Mailchimp, or other platforms, you can breach the limit quickly — causing permerror results that break authentication entirely. Audit your full SPF record with a lookup-count tool before publishing, and consider an SPF flattening or delegation service if you are close to the limit.

Step 3: Enable DKIM in AWeber

DKIM requires you to publish a public key as a TXT record in DNS. AWeber generates the key pair on its side; you publish only the public key. The general workflow is:

1. Log in to AWeber and open your account or domain settings.
2. Locate the email authentication, sender domains, or DKIM configuration section. AWeber's interface labels this area differently across account tiers — look for references to "domain authentication," "DKIM," or "custom domain."
3. Select the domain you want to authenticate.
4. AWeber will display a DNS record to publish — typically a TXT record with a name in the form selector._domainkey.your-domain.com and a value beginning with v=DKIM1; k=rsa; p= followed by a long base-64 public key string.
5. Copy both the record name (the selector) and the full record value exactly as AWeber displays them. Do not add or remove any characters.
6. Publish the record at your DNS provider using the name and value AWeber provided.
7. Return to AWeber and trigger any "verify" or "check DNS" step the platform offers to confirm it can see the published key.

The published DNS record will look similar to this (selector name will match whatever AWeber assigns):

; Name format
<aweber-selector>._domainkey.your-domain.com.  IN  TXT  "v=DKIM1; k=rsa; p=<public-key-string>"

Long key strings: Some DNS providers split TXT record values at 255 characters. If AWeber's public key is longer than 255 characters, you may need to enter it as two quoted strings side by side — your DNS provider's interface usually handles this automatically, but verify that the published record reassembles correctly when queried.

Step 4: Publish your DMARC record

Publish your DMARC record only after SPF and DKIM are in place and passing. Start with p=none — this policy instructs receiving servers to take no action on failing mail while still sending you aggregate reports. Run in monitoring mode for at least 14 days before moving to p=quarantine or p=reject. Rushing to enforcement without reviewing reports is the single most common cause of legitimate mail being blocked.

; DMARC record — monitoring mode, 14-day minimum before changing policy
_dmarc.your-domain.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-rua@dmarcbusta.pro; ruf=mailto:dmarc-rua@dmarcbusta.pro; fo=1; adkim=r; aspf=r; ri=86400"

Field reference for the record above:

Alignment note for AWeber: If AWeber's default return-path uses an AWeber subdomain rather than your own domain, SPF will fail DMARC alignment under strict mode. Relaxed alignment (aspf=r) covers this in most cases, but if you have configured a custom return-path using your own domain, strict mode is achievable. Review your AWeber account settings to determine which return-path is active before tightening alignment.

Step 5: Verify it works

Before sending a test email, confirm your DMARC record actually published. Use our free DMARC Checker to look up _dmarc.your-domain.com and verify the record is live, has the correct policy (p=none, quarantine, or reject), and is configured for aggregate reporting. While you are there, run the SPF Checker against your domain to make sure the SPF lookup tree is clean — once both records check out, the live email test below will give you the final confirmation.

After DNS changes propagate (allow up to 48 hours, though most providers update within minutes to a few hours), send a real message through AWeber to a Gmail or Yahoo Mail address you control. In Gmail, open the message, click the three-dot menu in the top-right of the message, and select Show original. In Yahoo Mail, select View raw message. Look for the Authentication-Results header near the top of the raw source.

A passing result looks like this:

Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce@your-domain.com designates 1.2.3.4 as permitted sender) smtp.mailfrom=bounce@your-domain.com;
       dkim=pass header.i=@your-domain.com header.s=<aweber-selector>;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=your-domain.com

• spf=pass — the sending IP is listed in your SPF record and the return-path domain matches
• dkim=pass — the message signature validates against the public key you published; the d= domain in the signature aligns with your From header domain
• dmarc=pass — at least one of SPF or DKIM passed and the relevant domain aligns with the RFC5322 From header

If any check shows fail or permerror, work backwards: check SPF first (use dig TXT your-domain.com to confirm the record is live), then DKIM (use dig TXT <selector>._domainkey.your-domain.com to confirm the key is published and intact), then review alignment.

Common errors with AWeber

• SPF record not updated or overwritten: Some DNS providers silently replace an existing TXT record with the same name rather than merging values. If you published a new SPF record and your old one disappeared, your other senders (Google, Office 365, etc.) are no longer authorised. Confirm you have exactly one SPF TXT record on your root domain containing all required includes.
• DKIM selector not found: The most frequent cause is a copy-paste error in the DNS record name — many providers auto-append the domain, meaning you should enter only the selector portion (<selector>._domainkey) rather than the full FQDN. Check your provider's interface behaviour before publishing.
• DKIM public key truncated: If the base-64 key string was entered as a single quoted string exceeding 255 characters and your DNS provider did not split it automatically, resolvers will return a malformed record. Query the live record with dig TXT <selector>._domainkey.your-domain.com and compare character-for-character against what AWeber shows.
• SPF lookup limit exceeded: AWeber's include, combined with other platform includes already in your record, can push you over the 10-lookup limit. The result is spf=permerror, which causes DMARC to fail on the SPF leg. Count your lookups with an SPF analyser tool and flatten or delegate as needed.
• DMARC alignment failure due to AWeber return-path: If you have not configured a custom return-path domain inside AWeber, the envelope sender (Return-Path) will use an AWeber-owned domain. SPF will pass for AWeber's domain, but it will not align with your From header domain. DMARC relies on the aligned pass, not just any pass. Either configure a custom return-path in AWeber or ensure DKIM alignment is passing to compensate.

How DMARC Busta helps

The steps above represent a one-time manual configuration. The harder ongoing problem is managing what happens next: new sending sources appear, SPF records drift over the 10-lookup limit, AWeber rotates infrastructure, and DMARC aggregate reports pile up in formats that require parsing. DMARC Busta is designed to manage these operational realities at scale — including environments with 10,000+ domains.

Autopilot mode monitors your DMARC aggregate reports and progresses your policy from p=none through p=quarantine to p=reject as your sending sources become fully authenticated — without manual intervention. SPF Auto-Repair handles SPF delegation and source management automatically, keeping you clear of the 10-lookup ceiling as your sending stack changes. Managed DMARC reporting parses and surfaces the data from every aggregate report so you can identify unauthenticated sources — like a misconfigured AWeber custom domain — before they affect deliverability.

Start your free trial and put your email authentication on autopilot.