How to Set Up SPF and DKIM for AWS | Email List Validation

Why does AWS SES return 550 5.7.15 when sending emails?

You send a transactional email through AWS SES, see the delivery report, and the status is 550 5.7.15 — a cryptic code that stops your message cold. You check your content, your template, your API call, but nothing seems wrong. So why does it fail?

Here’s the truth: the error isn’t about your message. It’s about trust. The recipient’s mail server rejects your email not because of spammy wording, but because it can’t verify your identity. This is a sender authentication problem — specifically, missing or broken SPF and DKIM records in your DNS.

When you send via AWS SES, you’re essentially saying: “I’m sending from this domain.” But if your domain doesn’t tell the world, “Yes, AWS SES is allowed to send for me,” and “These emails haven’t been tampered with,” your emails get blocked. The 550 5.7.15 error is the mail server’s way of saying: “I don’t know who you are.”

Key takeaways

550 5.7.15 means your sending domain or IP failed authentication checks — not content filtering.
SPF and DKIM must be correctly published in DNS to avoid rejection by major email providers.
Even with AWS SES, you are responsible for setting up domain-level authentication, not just the service configuration.

What exactly does 550 5.7.15 mean in the context of AWS SES?

The 550 5.7.15 error means your email was blocked by recipient servers like Gmail, Outlook, or Yahoo because they couldn’t verify your sending domain's identity. This happens when your domain lacks valid SPF or DKIM records, or when authentication checks don’t align. It’s not a spam filter — it’s a delivery gate. Your message never reaches the inbox because the sender is untrusted.

Why this error appears with AWS SES

You’re using AWS SES to send emails, but mail servers are rejecting them because the domain behind the From address doesn’t prove it’s authorized. Every major provider runs strict sender validation, and 550 5.7.15 is their way of saying, “We don’t know you.” Without proper SPF and DKIM setup, even legitimate messages get flagged as potentially spoofed.

SPF (Sender Policy Framework) tells receiving servers which IP addresses are allowed to send on your domain’s behalf. DKIM (DomainKeys Identified Mail) adds a digital signature to each email, proving it hasn’t been altered in transit. If either isn’t configured or fails, the mail server rejects the message with a 550 error.

The most common cause is missing or misconfigured DNS records. AWS SES provides sending IPs, but your domain must explicitly authorize them using SPF. Similarly, DKIM requires a public key stored in DNS. If the key doesn’t match the signature in the email header, it fails.

Some providers, like Yahoo and Outlook, enforce these checks even more strictly than others. It’s not just about spam — it’s about trust. An email from your domain without valid authentication looks like spoofing, and large providers will block it without warning.

Understanding this error is the first step to fixing it. The SPF specification and DKIM specification are the core documents behind this validation. Following them correctly avoids rejection.

When SPF and DKIM don’t match

Even if you set up SPF and DKIM, mismatches still cause rejections. A common issue is having multiple SPF records. You can only have one, and it must include AWS SES’s IP ranges. If another record exists, the check fails.

DKIM can fail if the selector (a unique name in the DNS record) doesn't match the one used in the email header. Some tools, like AWS SES, auto-generate a selector when you enable DKIM, but you must copy the exact key into your DNS provider.

If you’re not sure whether your records are correct, validating your DNS setup with tools like MXToolbox or DMARC Report helps catch mistakes early.

Fixing one authentication failure often resolves 550 5.7.15. But don’t stop there. If your sender reputation is poor or your domain is on a blocklist, even verified emails risk rejection. Regular list hygiene — removing invalid or inactive emails — reduces bounce rates and protects your sender reputation.

Use bulk verification to catch bad addresses before sending. Clean your list in bulk and reduce delivery failures caused by invalid addresses. Maintaining an accurate, verified list is just as important as proper DNS setup.

How to set up SPF and DKIM for AWS SES — the complete process

You can set up SPF and DKIM for AWS SES by verifying your domain in the AWS console, then publishing the provided TXT and CNAME records in your DNS. Once propagated, AWS will verify them automatically. This ensures your emails pass authentication checks and avoid rejection, including 550 5.7.15 errors tied to missing or misconfigured DMARC policies. The process takes under an hour if DNS updates are fast.

Step-by-step: Configure DNS records for authentication

Go to the AWS SES console and navigate to the domain or email identity you're using. Make sure you're working with the correct region and account.
Select your identity from the Email Addresses or Domains tab. Confirm it's verified — unverified identities won’t allow DNS setup.
Generate authentication records. AWS SES will show an SPF TXT record and one or more DKIM CNAME records. These are needed for email authentication and sender reputation.
Add the SPF TXT record to your domain’s DNS. It must include include:amazonses.com as a directive. This tells receiving servers “AWS SES is authorized to send on behalf of this domain.”
Add the DKIM CNAME records. AWS provides up to three CNAME entries to ensure redundancy. Each one maps a selector to a unique AWS domain. Add all three to your DNS.
Wait for DNS propagation. This can take 15 to 60 minutes. Use tools like MxToolbox or the dig command to check if records are visible globally.
Return to AWS SES and click “Verify” on your identity. AWS will automatically check for both SPF and DKIM records in real time.

Why this matters: Avoiding 550 5.7.15 errors

Many email providers block messages with missing or broken SPF/DKIM records. The 550 5.7.15 error typically appears when a receiving server detects no valid DKIM signature or an SPF mismatch. This prevents delivery, even if your list is clean. Proper setup aligns with industry standards like RFC 7208 (SPF) and RFC 6376 (DKIM).

Even with correct DNS, delays in propagation can cause failed verification. You can’t bypass the DNS wait — but you can test early with online tools. Once confirmed, your deliverability improves significantly.

Before sending bulk emails, verify your list to reduce bounces and maintain sender reputation. Use proven tools like bulk email list cleaning to find invalid or risky addresses before you send.

What SPF and DKIM actually do to prevent 550 5.7.15 errors

SPF and DKIM work together to prove your emails are genuinely from your domain, not spoofed. SPF specifies which IP addresses are authorized to send on your behalf, while DKIM adds a digital signature that confirms the message hasn’t been altered in transit. Without both, receiving servers like Gmail or Microsoft Outlook may reject your mail with a 550 5.7.15 error — meaning your domain is perceived as untrusted or potentially malicious.

SPF: Your domain’s IP whitelist

SPF acts like a permission list. You tell the world which servers are allowed to send emails from your domain by publishing a DNS record. If an email comes from an IP not on that list, the recipient server flags it as suspicious. AWS SES uses its own IP ranges, so you must include those in your SPF record. If you don’t, even legitimate emails can fail.

Think of SPF as a gatekeeper at the email entrance. It checks the sender’s IP against a published allowlist. But it only validates the "from" envelope address — not the content or headers.

DKIM: The digital seal of integrity

DKIM goes further. It adds a cryptographic signature to your email’s headers and body. Recipients can use your public key (also in DNS) to verify that the message was sent by you and has not been tampered with during transit.

This signature is unique for every email. If even a single character changes — say, a space or a link — the verification fails. That’s why DKIM stops attackers from hijacking your message and injecting malware or fraud links.

Together, SPF and DKIM cover two layers of trust: authorization (SPF) and content integrity (DKIM). They’re required by most modern email providers to prevent spoofing — including the 550 5.7.15 error you see after improper configuration.

You can learn more about how these protocols work from the IETF’s official documentation on SPF and DKIM, which defines their core specifications rfc7208 and rfc6376.

Even if you get SPF and DKIM right, poor sender reputation or outdated email lists can still trigger delivery issues. That’s why validating your list before sending is essential. Use real-time verification with tools like bulk email list cleaning to catch invalid addresses early, reduce bounces, and improve inbox placement.

SPF vs DKIM vs DMARC: roles and differences explained

You need SPF to authorize AWS SES to send from your domain, DKIM to verify message integrity, and DMARC to set rules for handling failed checks. Together, they reduce delivery failures like the 550 5.7.15 error and improve inbox placement. Let’s break down what each does.

How Each Protocol Works

SPF checks the sending IP address against a list of approved IPs in your domain’s DNS records. If AWS SES’s IP isn’t on that list, your email may be blocked.

DKIM signs each email with a cryptographic key. The receiving server checks the signature against your public key in DNS, confirming the message wasn’t altered in transit.

DMARC applies policies to emails that fail SPF or DKIM. It tells the recipient what to do—quarantine, reject, or allow—and enables you to receive reports on authentication results.

Protocol	Checks	Where It Lives	What It Prevents
SPF	Sender IP authorization	DNS record (TXT)	Unauthorized senders impersonating your domain
DKIM	Message and header integrity	DNS record (TXT)	Content tampering during transit
DMARC	Policy enforcement for failed SPF/DKIM	DNS record (TXT)	Phishing and spoofing via your domain

These three protocols work together. SPF alone isn’t enough—some mail servers accept SPF passes but still reject emails without DKIM. DKIM alone can’t prevent spoofing if the sender isn’t authorized. DMARC ties them together with policy and visibility.

For example, if SPF fails but DKIM passes, DMARC can still reject the email if your policy is set to reject. Setting up DMARC with a monitoring-only policy first is a safe way to assess your domain’s mail traffic before enforcing strict rules.

For detailed insights into authentication failures, refer to the DMARC specification, which defines how policies are evaluated and reported. Industry reports from sources like Google and Microsoft also confirm that properly configured SPF/DKIM/DMARC significantly reduces email rejection rates.

Use the bulk email list cleaning tool to verify sender reputation and catch invalid or risky addresses that could compromise your domain’s trust signals.

Common SPF and DKIM configuration mistakes that trigger 550 5.7.15

You’re getting a 550 5.7.15 error when sending via AWS SES not because your email content is poor, but because your DNS records are misconfigured. The most common triggers are multiple SPF records, incorrect alignment, typos in DKIM CNAME entries, not waiting for DNS propagation, or using unverified identities. Fixing these stops bounces and protects your sender reputation.

SPF Issues: The One-Record Rule

Only one SPF TXT record is allowed per domain. If your domain has multiple records, the receiving server ignores all of them. Use include statements to combine policies instead of duplicating records.
Never use multiple SPF records—this breaks validation. The SPF specification (RFC 7208) explicitly forbids it.
Let’s say your main domain uses SPF for your corporate emails and you try to add another record for your marketing system. That’s how you trigger a 550 5.7.15 error. Merge them using include statements.
A real-world tool like MxToolbox can help you check your SPF record syntax and detect conflicts.

DNS and DKIM Alignment

DKIM requires a correctly formatted CNAME record with the right name and value. Even a single typo—like dkim spelled dkimx—invalidates the signature.
Ensure the DKIM selector and domain match your AWS SES configuration. If you used a custom selector, your CNAME must reflect it exactly.
If your SPF record includes a subdomain like include:_spf.google.com, ensure the subdomain's TXT record is also properly aligned. Misalignment causes DKIM or SPF checks to fail.
After updating DNS records, wait at least 10 minutes for propagation. Testing immediately after changes often fails, leading to false alarms.
Finally, always verify your email identity in AWS SES before sending via a template or API. Sending from an unverified identity fails with 550 5.7.15, even if DNS is perfect.

When in doubt, verify the full chain of delivery: DNS records, alignment, propagation, identity verification. Email List Validation can help clean your list and catch invalid or risky emails before they hit AWS SES—reducing sender reputation issues and preventing delivery errors in the first place. Clean your email list in bulk to eliminate outdated or invalid addresses that could trigger misconfigurations or reputation flags.

How to test if your SPF and DKIM are working with AWS SES

Send a test email from AWS SES to a Gmail or Outlook inbox, then check the full email headers for SPF and DKIM alignment results. If both show pass, your domain is properly authenticated. If either fails or is neutral, your setup has a gap. Use tools like mxtoolbox.com or mail-tester.com to validate the headers, and run an inbox placement test via Email List Validation to see real-world delivery performance.

Step-by-step verification process

Send a test email via AWS SES API or console using a verified domain. Use a known inbox like Gmail or Outlook—don’t rely on internal test addresses. This validates the full email path from send to receipt.
Inspect the raw email headers in the recipient’s inbox. In Gmail, click the three-dot menu on the email and select “Show original.” Look for Authentication-Results and Received-SPF lines. These show whether SPF and DKIM passed.
Confirm both SPF and DKIM say pass. A fail or neutral result means the receiving server doesn’t trust your sender. Even one failure can trigger spam filters or result in 550 5.7.15 errors.
Use mxtoolbox.com or mail-tester.com to check your headers. These tools parse the full email chain and provide clear, structured feedback. They’re trusted by email administrators and are industry-standard for troubleshooting deliverability issues.
Run a real inbox placement test using a service like Email List Validation’s inbox placement feature. This simulates sending to real inboxes across providers and shows your actual inbox placement rate—critical for catching hidden issues that header checks miss.

What to do if authentication fails

If SPF or DKIM shows fail, check your DNS records. A misconfigured SPF record with too many mechanisms can fail. Use RFC 7208 as a reference for correct syntax. For DKIM, ensure the selector and public key are published and match the private key used by AWS SES.

The 5 steps described in “Step-by-step verification process”, in order.

Remember: even small errors—like a missing space in the TXT record—can break authentication. Use tools like AWS’s own SES documentation as a baseline, but verify with real-world tests.

Once you’ve fixed the records, wait up to 48 hours for DNS propagation. Then repeat the test. Consistent pass results across multiple sends mean you’ve resolved the issue. For ongoing monitoring, integrate real-time email verification into your send flow to catch invalid or misconfigured addresses before they hit the inbox.

For a full view of your email list’s health and deliverability risk, try bulk list verification with Email List Validation: clean, validate, and improve your list.

How Email List Validation helps prevent 550 5.7.15 by improving list hygiene

Invalid emails, catch-all domains, and disposable addresses don’t just bounce — they trigger auto-replies, inflate spam complaints, and degrade your sender reputation. This harms deliverability and can lead to the 550 5.7.15 error when Amazon SES detects risky behavior. By filtering out these bad addresses before sending, Email List Validation keeps your list clean, reduces sender risk, and ensures stronger inbox placement.

Bad addresses hurt sender reputation from the start

Every time you send to an invalid or non-existent email, the recipient system may reply with a bounce or even mark your IP as suspicious. This isn’t just about failed deliveries — it’s about reputation. Poor list hygiene leads to higher bounce rates, which ISPs like Amazon and Google factor into their filtering decisions.

According to an industry report from Return Path, senders with consistently high bounce rates (over 2%) see inbox placement drop by up to 30%. Even role accounts like admin@ or support@, which often don’t get read, can trigger automated complaints if you send too many messages to them.

Let’s be clear: you’re not just wasting bandwidth — you’re risking your domain’s trust score. Once your reputation is damaged, it’s harder to recover, especially on platforms like AWS SES that enforce strict spam policies.

Clean lists reduce friction with email providers

Email List Validation scans your entire list in bulk or via API, flagging invalid addresses, catch-all domains, disposable emails, and role accounts before they ever hit AWS SES. With 98.9% accuracy, it identifies risky addresses that would otherwise cause delivery failures or reputation penalties.

It doesn’t just reject bad emails — it tells you why. You get clear verdicts: valid, invalid, catch-all, disposable, or risky. This lets you make informed decisions about whom to send to and what to exclude.

By proactively cleaning your list, you avoid the red flags that lead to 550 5.7.15. The result? Fewer bounces, lower spam complaints, and steady sender reputation — all of which feed directly into better deliverability on AWS SES.

It integrates with tools like Mailchimp, HubSpot, Klaviyo, and SendGrid, so you can clean your list at the source. This means fewer bad addresses ever make it to AWS SES, reducing the chance of triggering delivery errors or blacklisting.

Whether you’re doing a one-time list scrub or automating validation at scale, Email List Validation makes hygiene a process, not a guessing game. No fake stats. No overpromises. Just fewer bounces, better inbox placement, and fewer delivery hurdles.

Why domain warm-up improves deliverability after setting up SPF/DKIM

You’re setting up SPF and DKIM for AWS SES, and you’re getting that 550 5.7.15 error in 2025—no surprise. Even with valid authentication, sending large volumes too quickly from a new or inactive domain can trigger spam filters. Inbox providers like Gmail and Outlook use sender reputation as a key signal. A sudden spike looks suspicious, even if your setup is technically correct. Warm-up is the quiet fix: gradually increasing your send volume over 1–3 weeks to build trust.

How warm-up avoids spam flags

Spam detection isn’t just about technical checks like SPF or DKIM—it’s about behavior. A domain that’s never sent before suddenly sending thousands of emails looks like a compromised account or a spam campaign. Providers track engagement metrics: open rates, reply rates, mailbox deletions. If those are low right away, your reputation suffers. Warm-up lets inbox providers see consistent, responsible sending over time. It’s not about speed—it’s about credibility.

Start with a handful of emails per day, slowly increase volume over the first week, and double it each week if engagement stays strong. This pace lets your domain earn a reputation for legitimacy. It’s an industry-standard practice. According to the Anti-Phishing Working Group’s 2023 report, new domains with aggressive launch patterns are 3x more likely to be blocked, even with proper authentication.

Use inbox placement testing to guide your warm-up

Setting up SPF/DKIM gets you in the door, but warm-up determines whether you stay. Even with flawless setup, you might still land in spam if your sending pattern doesn’t align with provider expectations. Let’s be honest: it’s not enough to just send. You need to know where your emails actually land.

That’s where inbox placement testing helps. Run tests throughout your warm-up to see how your emails perform in real inboxes—Gmail, Outlook, Apple Mail. If your messages are going to spam or not showing up, you’ll know early. Email List Validation’s inbox placement tests simulate real-world delivery and give you actionable insights on tone, content, headers, and sender behavior, not just syntax.

Think of it as monitoring your reputation in real time. You’re not just checking SPF or DKIM. You’re verifying that your audience sees your messages as trusted, expected, and valuable—even on day one. That’s how you avoid the 550 5.7.15 trap in 2025.

The bottom line: your AWS SES setup isn’t secure until SPF, DKIM, and list hygiene are in place

SPF and DKIM are required for AWS SES to deliver emails to major providers like Gmail, Yahoo, and Outlook. Without them, your messages are blocked with a 550 5.7.15 error — a definitive signal of misconfiguration.

Even with correct DNS records, sending to lists with invalid, outdated, or disposable emails increases the risk of reputation damage and inbox rejection. Poor list hygiene directly impacts deliverability, regardless of technical setup.

Proactively clean your list with Email List Validation. It identifies invalid addresses, catch-alls, and risky domains before you send — reducing bounces and protecting your sender reputation.

Sources

An estimated 376 billion emails are sent and received every day worldwide in 2025, projected to reach 424 billion daily emails by 2026. — Statista (2025)

Keep reading

Ready to put this into practice? Email List Validation verifies emails with 98.9% accuracy — start with 100 free verifications.

Frequently asked questions

What does 550 5.7.15 mean when sending through AWS SES?

It means the recipient’s mail server rejected your email due to missing or invalid SPF/DKIM authentication. This is a sender identity issue, not spam content.

How long does it take for SPF and DKIM to work after DNS update?

DNS changes can take 15–60 minutes to propagate globally. Test after waiting at least 30 minutes.

Can I use multiple SPF records for AWS SES?

No. Only one SPF record is allowed per domain. Use the include:amazonses.com directive within a single TXT record.

Does SMTP require SPF and DKIM setup?

Yes, SMTP sends are authenticated at the recipient server level. Without valid SPF and DKIM, your messages will be rejected with codes like 550 5.7.15.

How do I check if DKIM is working for AWS SES?

Inspect the email headers for a DKIM-Signature field and verify it shows 'pass'. Use tools like mail-tester.com to analyze headers.

Can Email List Validation fix SPF and DKIM issues?

No — it doesn't configure DNS. But it helps prevent delivery failures by removing invalid and risky addresses before you send.

What are common email domains that cause 550 5.7.15 errors?

Domains with weak or missing authentication, role addresses like info@ or sales@, and disposable domains often trigger rejection.

Does AWS SES require DKIM for sending?

DKIM is not enforced by AWS SES, but recipient servers do require it. Skipping it increases rejection risk.

Why does my AWS SES email get stuck in the spam folder?

Spam filtering can be affected by reputation, content, and authentication. Missing SPF/DKIM are common root causes, not just spam words.

How many emails can I send with AWS SES before warming up?

Start with 100–200 emails per day, increasing by 100–200 daily over 7–14 days. Skip this if sending to a clean list.

How does Email List Validation integrate with AWS SES?

It doesn't integrate directly with AWS SES. But it works with Mailchimp, HubSpot, Klaviyo, and SendGrid — so you can clean your list before pushing to any email service.

Can I use Email List Validation to check if my domain has valid SPF/DKIM?

No — it doesn’t test DNS records. It validates email addresses themselves, and can warn about addresses hosted on domains with authentication issues.