Issue:
A new customer using Google Workspace after migrating to our platform realized that he or she was unable to send emails. The error message she was getting was:
TLS_AES_256_GCM_SHA384:256 CV=yes: SMTP error from remote mail server after end of data: 550 5.7.1 This sender is not authorized to send from example_domain.com.
While there are several factors that could trigger this error, this usually indicates an issue with email authentication or domain spoofing protection mechanisms like SPF, DKIM, and DMARC. In this case, the issue was the the TXT records transferred was using the source hosting providers instead of WebHostingM's. This guide will walk you through the troubleshooting process for WebHostingM cloud hosting accounts, specifically focusing on the cPanel and Plesk environments. Let's explore this further.
Email authentication protocols such as SPF, DKIM, and DMARC are essential to protect your domain from unauthorized senders (spoofers) and malicious activity. Without these, anyone can send emails that appear to come from your domain, potentially damaging your reputation or even leading to phishing or malware distribution.
There are three key email authentication protocols that protect against unauthorized email sending:
- DKIM (DomainKeys Identified Mail): Allows the receiver to verify that the email was authorized by the owner of the domain using a digital signature.
- SPF (Sender Policy Framework): Verifies that the email’s sending path matches the authorized sending hosts listed in the domain's DNS records.
- DMARC (Domain-based Message Authentication, Reporting, and Conformance): Builds on SPF and DKIM, providing a policy for handling messages that fail authentication.
While SPF and DKIM work well for basic email authentication, in multi-tenant environments like ours, it is often insufficient. That’s where MailChannels Domain Lockdown™ comes in.
WebHostingM uses MailChannels to deliver email securely and reliably. It acts as an another layer to shield to filter out spam, phishing, and malware before they even reach your inbox, ensuring your email traffic is secure. This means that any attempts to send email from an unauthorized account or server will be blocked to prevent malicious activity.
How Domain Lockdown™ Prevents Unauthorized Sending
Domain Lockdown™ ensures that only authorized accounts or users can send email on behalf of your domain. By setting a simple DNS TXT record, you can specify which MailChannels accounts or senders are allowed to send mail from your domain. If an unauthorized attempt is made, the email will be rejected with a 550 error, like the one you received.
Troubleshooting to Fix the 550 5.7.1 Error
Follow the steps below to resolve the 550 error and ensure that only authorized senders can send mail from your domain.
1. Create or Update the DNS TXT Record
The first step is to create or update a DNS TXT record for your domain to specify which MailChannels account IDs or sender IDs are authorized to send email. Let's see how you can do this for your domain:
Before making changes to your DNS, we recommend:
Disclaimer
- using our JetBackup to back up the current DNS settings. That way if anything goes awry, you can restore the former configurations.
- reducing the TTL to something around 300 seconds (5 minutes) for faster propagation.
- for "root", test any changes in a staging environment before applying these troubleshooting steps in a live environment.
- if the need be, consult the latest cPanel and/or Plesk documentation for updates.
- For cPanel users: Go to Zone Editor > Select your domain > Add a new TXT record or edit an existing record.
- For Plesk users: Go to DNS Settings for your domain > Add a new TXT record or edit an existing record.
It’s important to verify that no conflicting or incorrect TXT records are present. A common cause for this error is an incorrect record like:
_mailchannels.example_domain.com. 3600 IN TXT "v=mc1 auth=$oldvalue"
where $oldvalue may be the former web hosting provider or another name.
The name of the record should be _mailchannels.example_domain.com (replace example_domain.com with your actual domain name). The value of the record should specify the MailChannels account ID or sender ID, using the following format:
v=mc1 auth=webhostingm senderid=$mysenderid
This record authorizes the MailChannels account "webhostingm" (your WebHostingM account) and the sender ID "$mysenderid" to send mail on behalf of your domain.
2. Save the DNS Record
After adding the TXT record, save the changes in your DNS settings. DNS changes may take some time to propagate across the internet, typically 15-30 minutes, but it may take up to 48 hours in rare cases.
3. Verify the DNS Record
Use an online DNS lookup tool, such as What's My DNS, to verify that your new TXT record has been propagated. The record should appear like this:
_mailchannels.example_domain.com. 3600 IN TXT "v=mc1 auth=webhostingm"
Make sure the value of auth is set to the correct MailChannels account ID or sender ID (e.g., webhostingm) that you want to authorize to send emails on your behalf.
Other Examples TXT Records
- Allowing only one MailChannels account to send from your domain:
v=mc1 auth=webhostingm
- Allowing two MailChannels accounts to send from your domain:
v=mc1 auth=webhostingm auth=anotherprovider
- Locking down a specific Sender-ID:
v=mc1 senderid=webhostingm|x-authuser|$username
- Blocking all email sending for your domain:
v=mc1
Make sure the value of auth is set to the correct MailChannels account ID or sender ID (e.g., webhostingm) that you want to authorize to send emails on your behalf.
4. Testing Email Functionality
After DNS propagation is complete, try sending an email again from the affected account again to see if the issue persists. If you continue to receive the error, proceed with the following steps.
5. Check SPF, DKIM, and DMARC Records
Ensure your SPF, DKIM, and DMARC records are configured correctly:
- SPF Record: Verify that the SPF record includes MailChannels’ IP range, and that there are no conflicting entries that might block outgoing mail.
- DKIM Record: Confirm that DKIM is set up and matches the signing key used by MailChannels.
- DMARC Record: Ensure that your DMARC policy aligns with your SPF and DKIM configurations.
6. Test via Command Line
If you’re comfortable with the command line, use the sendmail or mail commands to send a test email from the server. Here’s how you can do it:
Using sendmail:
echo -e "Subject: Test Email\nFrom: tiff@example_domain.com\nTo: example_domain@gmail.com\n\nThis is a test email from cPanel troubleshooting." | /usr/sbin/sendmail -t
Using mail:
echo "This is a test email from cPanel troubleshooting." | mail -s "Test Email" -r tiff@example_domain.com example_domain@gmail.com
Visit Email >> Send Report and check to see if the current state of the sent email. Or check your inbox for the email.
If you are a VPS or a dedicated server customer with access to "root", check the email logs in /var/log/maillog to identify any issues with the sending process.
7. Temporary Blocks & Access
If multiple failed sending attempts have been made, our security systems may temporarily block the sending account. Wait 30 minutes to 1 hour and then try again. If in a hurry or if the issue persists, contact security team to remove any blocks on your account.
Other Common Causes of 550 5.7.1 Errors
As stated before, there ma be other several common causes for this error, including:
- High volume of emails sent in a short period.
- Sending email to invalid or non-existent email addresses.
- Being flagged for spammy behavior or high complaint rates.
If you believe one of these is the issue, contact WebHostingM support for further investigation.
Best Practices to Avoid Future 550 Errors
- Ensure all your email authentication records (SPF, DKIM, DMARC) are configured correctly and up to date.
- Regularly monitor your email sending patterns to avoid being flagged as spam.
- Clean up your email lists to remove invalid addresses and prevent sending to non-existent recipients.
