Fix AWS SES 550 5.7.15 | Email List Validation

What Causes the 550 5.7.15 Error in AWS SES?

You try sending a transactional email through AWS SES, and it fails. The bounce message says “550 5.7.15” — no explanation, no guidance. You double-check your credentials. The content is fine. Yet the email doesn’t land.

This error isn’t about your message. It’s about identity. AWS SES rejects the email because your domain isn’t verified, or the underlying DNS records for SPF, DKIM, or DMARC are missing or misconfigured. The receiving server sees the email as untrusted, and blocks it immediately.

The 550 5.7.15 error is a gateway check. It’s not a temporary glitch. It’s a hard rejection based on failed verification. Even a perfect email body gets rejected if the domain identity isn’t proven.

Key takeaways

The 550 5.7.15 error in AWS SES is triggered by a missing or failed domain verification.
Even with correct credentials and valid content, an unverified domain results in immediate rejection by receiving servers.
Verifying DNS records for SPF, DKIM, and DMARC is required to resolve 550 5.7.15; misconfiguration in any one of them can cause the error.

Why Domain Verification Is Mandatory for AWS SES

You must verify your domain with AWS SES to prove ownership and prevent abuse—without it, email from your domain is likely blocked by Gmail, Outlook, and Yahoo as spam. AWS enforces this step because unverified domains are a common vector for spam campaigns, and verifying ensures you’re a legitimate sender.

Preventing Abuse and Protecting Sender Reputation

AWS SES requires domain verification as a baseline security measure. Spammers often forge sender domains, so AWS needs to confirm you’re the real owner before allowing you to send emails at scale. This helps maintain the integrity of email delivery across the internet.

Without verification, any message sent from your domain risks being flagged or blocked by major providers. For example, Gmail uses sender reputation metrics heavily, and unverified domains often start with a poor reputation, even if your content is legitimate.

How Verification Enables Reliable Sending

Once verified, AWS can enforce sender policies, track domain-level sending behavior, and protect your domain from misuse. It also lets AWS apply domain-specific filtering rules and helps resolve delivery issues like 550 5.7.15 errors.

Domain verification is how AWS ensures you’ve got control over the domain name, DNS records, and associated email infrastructure. This is a standard practice for all major email delivery platforms, including Google Workspace and Microsoft 365.

After verification, you can set up SPF, DKIM, and DMARC records more confidently. While AWS doesn’t require them for sending, they’re essential for high deliverability. You can use bulk email list cleaning to remove invalid or risky addresses from your campaigns before sending, reducing bounce rates and improving domain reputation.

According to RFC 5321 (the core SMTP specification), email senders must be accountable. While that doesn’t mandate verification, it underpins why platforms like AWS SES implement it. The same principle applies to domain policies enforced by organizations like Spamhaus and MxToolbox—entities that track abuse patterns across the global email ecosystem.

Think of domain verification as the first step in proving you’re not a spoofing attacker. It’s not just a formality—it’s how AWS separates real senders from bots and spammers. If you’re seeing a 550 5.7.15 error, your domain is likely still unverified or has a failed policy check.

The Correct AWS SES Domain Verification Process

To resolve the 550 5.7.15 error in AWS SES, you must complete the domain verification process: add two CNAME records to your DNS provider for DKIM and identity validation, wait for propagation (1–30 minutes), then confirm status in the AWS Console. Failure to do so results in rejected emails and delivery failures.

Step-by-Step Verification Setup

Log in to the AWS Console and navigate to Amazon SES in your selected region. AWS SES requires explicit domain verification before sending, so skip this step and you’ll get a 550 5.7.15 error — a common blocker for new users.
Select 'Domains' from the left sidebar and click 'Verify a New Domain'. This starts the identity verification workflow. AWS uses this to confirm you own the domain and are authorized to send emails from it.
Enter your domain (e.g., example.com) and click 'Verify Domain'. AWS will generate two DNS CNAME records: one for DKIM signing (for message integrity) and one for identity verification (to prove ownership).
Add both CNAME records to your DNS provider — whether it’s Route 53, Cloudflare, GoDaddy, or another. These records must match exactly as shown. Missing or incorrect entries cause verification to fail.
Wait for DNS propagation. This typically takes 1–5 minutes but can take up to 30 minutes depending on your provider’s TTL settings. Avoid checking status too early. A common mistake is assuming immediate propagation.
Return to AWS SES and click 'Check Status' on the domain. Once AWS detects the records, it will update to 'Verified'. Only then can you send emails from that domain without a 550 5.7.15 error.

Why This Process Matters

Without proper domain verification, AWS SES blocks outbound emails to prevent spoofing. This is the foundation of email authentication. The DKIM record ensures messages aren’t altered in transit, while the identity verification proves you’re the rightful owner. These are standard practices verified by RFC 5322 and enforced by major email providers like Gmail and Outlook.

The 6 steps described in “Step-by-Step Verification Setup”, in order.

If you're sending large volumes, verifying your domain upfront prevents bounce-heavy campaigns and keeps your sender reputation intact. For reference, unverified domains have a near-zero inbox placement rate. You can avoid sender reputation degradation by catching issues before sending — bulk email list validation helps ensure your address list is clean before you even hit AWS SES.

Common DNS Configuration Mistakes That Break Verification

Even a single misplaced character in your DNS records can halt AWS SES domain verification. You might see a 550 5.7.15 error not because of AWS, but due to a typo in a CNAME value, using TXT instead of CNAME, or skipping the full record name like mail.example.com. These small mistakes are the most frequent cause of failed validation. Let’s break down what goes wrong and how to fix it.

Typo or Case Sensitivity Issues in CNAME Records

Double-check the exact name and value of the CNAME record — even a missing hyphen or incorrect capitalization breaks the validation. DNS is case-sensitive for the name but not for the value; always verify using a real DNS lookup tool.
Some DNS providers silently normalize values — don’t assume it’ll fix your typo. Use dnschecker.org to inspect your record from multiple global locations before assuming it’s live.
Let’s say you meant to enter mail._domainkey.example.com but typed mail._domainkey.example.com. with a trailing dot — that’s a different record. No room for error.

Using TXT Instead of CNAME for Identity Verification

AWS SES requires CNAME records for domain identity verification. If you added a TXT record instead, the validation fails silently. This is a common mix-up with SPF or DKIM setups.
SPF, DKIM, and DMARC all use TXT records; identity verification in SES uses a CNAME. Confusing them is a standard mistake — check AWS’s official guide on domain verification procedures.
Don’t rely on auto-configuration tools that suggest TXT records — they’re for other purposes. For SES domain verification, it’s a CNAME only.

Missing Full Record Name or Misplaced Subdomain

Don’t just enter mail — the full name is mail.example.com. Omitting the domain or using just a subdomain like mail will not match AWS’s expected format.
Your DNS record must exactly match the one AWS provides. If the system says CNAME: mail._domainkey.example.com, then mail._domainkey.example.com must be the complete name — no shortcuts.
Use your DNS provider's zone editor to verify both the name and value are entered precisely as instructed.

Assuming DNS is Live Too Soon

Even after updating DNS, it can take up to 48 hours for propagation. Some tools report “not propagated” during that window — this is expected, not broken.
Don’t retry verification every 5 minutes. Test with MXToolbox or dnschecker.org to confirm the record appears globally before assuming failure.
Always wait at least 30 minutes after update, and prefer verification checks after 2–4 hours to avoid false negatives.

Preventing these issues before you send an email matters — a failed verification means no access to Amazon’s sending infrastructure. The fix is simple: check each character, use only CNAME for identity, use full names, and be patient with DNS propagation.

How to Verify a Domain Successfully Using AWS Console

You verify a domain in AWS SES by copying the exact CNAME records from the AWS Console, adding them to your DNS provider with the correct type and trailing dots, confirming they’re live using a DNS lookup tool like MxToolbox, waiting five minutes, then refreshing AWS SES. Do not send emails until the status shows verified. This avoids 550 5.7.15 errors caused by unverified domains.

Step-by-Step Domain Verification in AWS Console

Go to the Amazon SES console and select the region where your domain will be used. Ensure you're in the same region where the domain will be verified, as SES operates per region.
Under "Domains," click "Verify a New Domain." AWS will generate two CNAME records required for verification. Copy the full record name and value exactly as shown, including any trailing dots after the domain name.
Log in to your DNS provider (e.g., Route 53, Cloudflare, GoDaddy) and create two new CNAME records. Use the record name and value as copied from AWS. Make sure the record type is set to CNAME and not a different type like TXT or A.
Use a tool like MxToolbox or the command-line dig to verify the CNAME records are now publicly visible and resolve correctly. A delay of up to 48 hours is possible, but most changes take minutes.
Return to the AWS SES console and refresh the domain status. Wait at least five minutes after DNS propagation to check again. A successful verification will show “Verified” in the status column.
Only after seeing “Verified” should you attempt to send email. Sending earlier causes 550 5.7.15 errors, as email servers reject unverified domains to prevent abuse.

Common Pitfalls and How to Avoid Them

One frequent mistake is omitting the trailing dot in the record value. AWS includes it to denote a fully qualified domain name; leaving it out breaks the validation. Another is using the wrong record type — TXT is not accepted for SES domain verification.

Even after successful DNS changes, some systems enforce a cache delay. You can test propagation with RFC 1034, which defines DNS naming conventions and expected behavior. When in doubt, wait five minutes and check again.

Once verified, you can use AWS SES to send email from that domain. For high-volume or complex senders, combine domain verification with sender identity policies and monitoring tools like AWS CloudWatch to track delivery performance.

What to Do If AWS SES Domain Verification Still Fails

If your AWS SES domain verification keeps failing with error 550 5.7.15 2025, it’s likely due to a DNS misconfiguration, region mismatch, or conflicting ownership. Check your DNS records for typos using a public lookup tool like MXToolbox; ensure the domain isn’t already verified in another AWS account; confirm you're in the correct AWS Region; wait at least 30 minutes after DNS changes; and if the issue persists, contact AWS Support with the full error log and domain.

Verify DNS Configuration Correctly

Use a public DNS lookup tool such as DNSChecker.org to confirm the TXT record for AWS SES is published and matches exactly what AWS provided — not just the value, but the full record format, including quotes.
Check for common errors: missing or extra spaces, incorrect record type (make sure it’s TXT, not CNAME or SPF), or a domain typo (e.g., example.com vs example.org).
Verify the record is not being overridden by a caching DNS provider or CDN, which can delay propagation up to 48 hours, even if the record is correct.

Confirm Ownership and Region Settings

Domains in AWS SES are tied to a single account. If another AWS account already owns the domain, you cannot re-verify it. Use AWS Support to check ownership status.
Ensure you’re in the same AWS Region where you initially created the domain identity in SES. Domains verified in us-east-1 cannot be used in eu-west-1 without re-verification.
Wait at least 30 minutes after making DNS changes before retrying verification. DNS propagation delays are common, and the service may not detect updates immediately.
If nothing works, gather the full error message (including the 550 5.7.15 2025 code), domain name, and region, then contact AWS Support directly — they can diagnose backend issues or ownership conflicts.

Even a single character error in a TXT record can halt delivery. Double-checking is not tedious—it’s necessary.

After resolving the verification issue, use a tool like bulk email list cleaning to verify your sender list’s health and reduce bounce risk — especially if you're sending to many domains across multiple regions.

How to Prevent Future 550 5.7.15 Errors After Verification

After completing the AWS SES domain verification process, prevent 550 5.7.15 errors by maintaining proper DNS records (SPF, DKIM), monitoring sender reputation, avoiding risky domains, and cleaning your email list before sending. These steps reduce bounce rates, improve inbox placement, and avoid blacklisting.

Keep Your DNS Configuration Active and Correct

Maintaining SPF and DKIM records in DNS is critical. If either is missing, misconfigured, or expired, receiving servers will reject your messages—even after domain verification. You might see a 550 5.7.15 error if your DKIM signature fails validation or SPF doesn’t recognize AWS SES as an allowed sender. Use tools like MXToolbox to verify DNS records in real time.

Let’s be clear: AWS SES doesn't auto-fix your DNS. You’re responsible for keeping SPF include statements accurate (e.g., include:_spf.amazonaws.com) and DKIM keys rotated when needed. Losing one of these can trigger 550 5.7.15 errors without warning. Monitor changes with automated checks or manual audits at least monthly.

Monitor Sender Reputation and Clean Your List

Even with correct setup, sending to invalid or high-risk addresses harms your sender reputation. ISPs and email providers track how often your messages bounce or get marked as spam. A growing bounce rate can trigger automatic sending limits or temporary blocks—often signaled by a 550 5.7.15 error.

Use AWS SES’s built-in metrics to track delivery rates, bounce rates, and complaint rates. Combine this with third-party tools like Return Path’s Intelligence Center or Mail-Tester to evaluate your overall deliverability. These tools help catch issues early, before reputation damage escalates.

If you’re sending to a large list, use a service like bulk email list cleaning to filter out invalid, disposable, or role accounts before sending. This reduces bounces, protects your reputation, and improves inbox placement. You don’t need to guess—tools can identify and flag high-risk domains like 10minutemail.com or [email protected] before you send.

Pro tip: avoid frequently blocked domains. Some domains have high spam risk due to their history or open registration. You can manually block these, or use list verification tools that flag them automatically. This is not a one-time fix—maintenance is ongoing.

How Email List Validation Helps Avoid Deliverability Errors

You can prevent 550 5.7.15-like deliverability failures by filtering out invalid, role-based, and disposable email addresses before sending. These bad addresses hurt your sender reputation and increase bounce rates, especially when sending at scale through AWS SES. Email List Validation scans your list in bulk or in real time to flag risky addresses so you send only to inbox-ready recipients, reducing the chance of rejection due to poor deliverability signals.

Preventing Rejection with Pre-Send List Hygiene

When you send emails through AWS SES, a failed domain verification or poor sender reputation can trigger hard bounces like 550 5.7.15. These indicate policy-level blocking—often because your sending domains aren’t properly aligned with SPF/DKIM, or your list includes addresses that generate high spam complaints. Email List Validation catches these issues early by analyzing each email for validity, risk level, and inbox placement likelihood.

For example, role-based addresses like admin@ or sales@ frequently get blocked by enterprise filters because they don’t represent actual individuals. Disposable email domains (like mailinator.com) are often used for spam and are automatically filtered. Email List Validation identifies these early and flags them as “risky” or “invalid,” so you can clean them before sending. This reduces bounce rates and protects your reputation — a key factor in maintaining consistent inbox delivery.

Automating Clean Lists Across Your Stack

Instead of manual cleanup, integrate Email List Validation directly with your tools. The real-time API allows you to validate addresses as they enter your system, while the bulk verification tool helps you clean existing lists before campaigns. If you use SendGrid, Mailchimp, HubSpot, or Klaviyo, the integrations handle the entire workflow for you: scan, clean, and send — all without switching apps.

Tools like AWS SES depend on sender reputation to determine inbox placement. Every hard bounce or complaint hurts your score. A 2023 report from Return Path found that lists with high invalid rates (over 5%) often trigger filtering by major providers. By removing risky addresses upfront, you maintain a cleaner sender profile and avoid the kind of 550 5.7.15 errors tied to poor sending practices. You’re not guessing if an email is deliverable — you know.

See how it works: clean large lists in minutes or integrate verification in your signup flow with just one API call.

Real-World Impact: What Happens If You Skip Domain Verification?

If you skip AWS SES domain verification, your emails won’t get past the receiving server’s SMTP handshake — they’ll be rejected with the 550 5.7.15 error, meaning your domain isn’t authorized to send through AWS SES. You’ll see a bounce rate that spikes above 50%, even with perfect content, because the receiving server outright refuses the connection. This isn’t a temporary glitch — it’s a complete block until domain verification is completed, and your IP or domain could be flagged by spam filters, leading to long-term deliverability issues.

Why 550 5.7.15 Happens at the SMTP Level

When you send via AWS SES without verifying your domain, the receiving server checks the sending domain against its allowed list. The 550 5.7.15 error means the server knows your domain doesn’t have a valid authorization record. Unlike a content-based block, this happens before the email body is even processed — it’s a hard reject at the transport layer.

Mail servers use standards like DMARC, SPF, and DKIM to validate the authenticity of sending domains. Without domain verification in AWS SES, these records aren’t properly aligned or published, so the server assumes the message is either forged or coming from an untrusted source. This is not unique to AWS — it’s an industry-standard mechanism enforced by major providers like Gmail and Outlook.

According to RFC 5321, the SMTP protocol allows receiving servers to reject messages based on policy, and 550 5.7.15 is a documented response code for such rejections. In practice, this means any email sent before verification will be dropped without a delivery attempt.

The Ripple Effect: From Rejections to Blocklists

Even a single batch of unverified emails can trigger red flags. Many receiving servers track sending behavior and IP reputation. If you send hundreds of emails with a 550 5.7.15 rejection rate, the server may log your sending IP as inconsistent or unauthorized, leading to potential blacklisting.

Some ISPs will place your IP on temporary blocklists if they detect repeated failures in domain authentication. Recovery from these can take days to weeks, even after verification is completed. You may also lose access to email services that perform sender reputation checks — like Mailchimp or SendGrid — if your underlying infrastructure is flagged.

It's not just about getting past the initial rejection. Skipped verification sets off a chain reaction: high bounce rates mess with your sender reputation, reducing delivery to real inboxes over time. The result? Your campaigns get ignored, and your engagement metrics plummet — even with high-quality content and proper list hygiene.

Even if you’re using a clean email list, a failed domain verification still breaks delivery. You can’t bypass this layer — it’s not optional. The only fix is completing the domain verification process in AWS SES: adding DNS records to prove domain ownership. Until then, your emails don’t go anywhere.

For teams managing high-volume sends, catching authentication issues early is critical. Tools like bulk email list cleaning can help identify risky addresses, reduce bounces, and keep sender reputation intact — but they won't fix a missing domain verification. Authentication starts at the domain level.

Domain Verification Is Not a One-Time Task

You must re-verify your AWS SES domain whenever you change your infrastructure, switch accounts, or use new subdomains. DNS records can be altered by third parties, misconfigured during updates, or removed accidentally. Left unchecked, these issues trigger 550 5.7.15 errors in email delivery. Regular validation ensures your sender reputation stays intact, and you avoid blacklists. Think of it as a routine system audit — not a setup checkbox.

When Verification Must Be Re-Run

After switching from one email provider to another — even within AWS — re-verify each sending domain or subdomain to prevent delivery failures.
If you spin up new subdomains (like newsletters.yourcompany.com) for dedicated campaigns, each must be verified separately in SES, even if the parent domain is already verified.
When transferring domain ownership to a new AWS account, the old account loses permission to send. Re-verification is required from the new account owner’s console.
Updates to DNS records by a third-party vendor (e.g., your hosting provider) may overwrite or delete your SES verification records. Confirm they remain intact.

Proactive Checks to Avoid 550 5.7.15 Errors

Even if verification succeeded once, your delivery pipeline can break silently. Tools like Email List Validation’s bulk verification help you identify invalid or risky addresses before sending. This reduces bounce rates and protects sender reputation — a major factor in inbox placement.

Regularly check your DNS records using a trusted service like MxToolbox or RFC 5322, which defines email address syntax and delivery standards. These tools validate that your SPF, DKIM, and DMARC records are correct and not inadvertently modified. Even a small typo in a TXT record can cause authentication failures.

Let’s be clear: DNS is stateful. A correct record today doesn’t guarantee it’ll be correct tomorrow. Your infrastructure changes, team members update settings, or a misconfigured script runs. That’s why automated auditing — like integrating real-time email verification into your signup flows — is essential. Catching risky or invalid emails early avoids the 550 5.7.15 error in production.

Conclusion: Fix 550 5.7.15 by Verifying Your AWS SES Domain Correctly

The 550 5.7.15 error is not caused by email content, sender reputation, or email body formatting. It points directly to incomplete or incorrect domain verification in AWS SES.

Ensure you follow AWS SES’s domain verification steps precisely. Double-check the TXT record in your DNS configuration, allow sufficient time for DNS propagation (typically 1–5 minutes, up to 24 hours in rare cases), and verify the status in the AWS Console before sending.

Domain verification is not a one-time fix. It’s foundational for sender identity, authentication, and long-term deliverability. Regular list hygiene, using tools like Email List Validation, helps maintain high inbox placement and prevents future errors.

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

How long does AWS SES domain verification take?

It typically takes 1–5 minutes after DNS propagation, but can take up to 30 minutes depending on your DNS provider.

Can I send emails from AWS SES without verifying my domain?

No. Sending from unverified domains will result in 550 5.7.15 errors. Verification is mandatory.

What DNS records does AWS SES require for domain verification?

AWS SES requires two CNAME records: one for DKIM and one for identity verification. TXT records are not used.

Why does my domain show ‘Verifying’ in AWS SES for hours?

Wait at least 30 minutes after DNS changes. Check DNS propagation using tools like MxToolbox or dig.

Can I verify multiple domains in AWS SES?

Yes, you can verify multiple domains. Each requires its own set of CNAME records and verification step.

Does domain verification affect my sender reputation?

Yes. Verified domains are more trusted by receiving servers and improve long-term deliverability.

What happens if I delete a verified domain from AWS SES?

You must re-verify the domain to send emails again. The DNS records remain active unless removed.

Can I use Email List Validation with AWS SES?

Yes. You can verify email lists before sending via AWS SES to reduce bounces and protect reputation.

How does Email List Validation improve deliverability with AWS SES?

It removes invalid, disposable, and role-based addresses, reducing bounce rates and protecting sender reputation.

Do I need to verify my domain every time I send?

No. Once verified, the domain can be used indefinitely unless the DNS records are changed or the account is deactivated.