550 there are no mx records nor a records for domain что это
Перейти к содержимому

550 there are no mx records nor a records for domain что это

  • автор:

Ошибка 550 Administrative prohibition

Для решения проблемы необходимо проверить текущие MX-записи и, если они прописаны некорректно, изменить их.

Проверка текущих MX-записей

Перейдите на страницу online проверки DNS-записей. Введите имя домена, в выпадающем списке выберите тип записи «MX» и нажмите Проверить.

  • если вы пользуетесь почтой на виртуальном хостинге Рег.ру, в выводе должны фигурировать:
    mx1.hosting.reg.ru и mx2.hosting.reg.ru ;
  • если вы пользуетесь Yandex почтой:
    mx.yandex.ru ;
  • если вы используете Google Workspace:
    ALT2.ASPMX.L.GOOGLE.COM
    ASPMX2.GOOGLEMAIL.COM
    ASPMX3.GOOGLEMAIL.COM
    ASPMX.L.GOOGLE.COM
    ALT1.ASPMX.L.GOOGLE.COM
  • если вы пользуетесь почтой Mail.ru:
    emx.mail.ru .

MX-записи прописаны верно

Если MX-записи прописаны верно, а почта всё равно не отправляется, причина связана с тем, что с момента изменения MX-записей (или DNS для домена) еще не прошло 24 часа.

MX-записи прописаны некорректно или вовсе отсутствуют

В этом случае вам просто необходимо прописать корректные MX-записи. Для начала необходимо определить, какие DNS-сервера прописаны для вашего домена. Именно на этих DNS-серверах нужно будет прописывать корректные MX-записи.

Перейдите к сервису Whois, введите название вашего домена и нажмите Проверить.
Возможны следующие варианты:

  • прописаны DNS-серверы «ns1.hosting.reg.ru» и «ns2.hosting.reg.ru».
    В этом случае прописывать MX-записи необходимо в панели управления хостингом:
    Как это сделать для почты Рег.ру
    Как это сделать для Yandex-почты
    Как это сделать для Google Workspace
    Как это сделать для Mail.ru
  • прописаны DNS-серверы «ns1.reg.ru» и «ns2.reg.ru».
    Прописывать MX-записи необходимо в личном кабинете на сайте Рег.ру (или в личном кабинете партнера Рег.ру (например, 2domains), если домен приобретался через него).
    Если вы хотите пользоваться почтой на виртуальном хостинге Рег.ру, проще всего будет изменить DNS-сервера на хостинговые, при этом хостинговые MX-записи настроятся автоматически.
  • прописаны DNS-серверы «ns5.hosting.reg.ru» и «ns6.hosting.reg.ru».
    MX-записи необходимо прописывать там, где производилась первоначальная настройка DNS для домена. Это может быть:
  1. панель управления (ISPmanager, Parallels Plesk);
  2. dnsadmin.

Если вы хотите управлять почтовыми ящиками на VPS-сервере, вам необходимо внести следующие ресурсные записи:

Имя записи Тип записи Значение Приоритет
domain.ru. MX (почтовый сервер) mail.domain.ru. 1
domain.ru. TXT (текстовая запись) v=spf1 ip:123.123.123.123. a mx ~all
mail.domain.ru. A 123.123.123.123
  • для домена прописаны другие DNS-сервера.
    В этом случае обратитесь к поставщику DNS вашего домена. Если вы хотите пользоваться почтой Рег.ру, на сторонних DNS необходимо прописать соответствующие ресурсные записи. Ресурсные записи для VPS приведены выше, ресурсные записи почты виртуального хостинга приведены здесь.

Помогла ли вам статья?

Спасибо за оценку. Рады помочь ��

Fix Mailgun “550 Sender has no A, AAAA, or MX DNS records.”

Emails floating about

Sometimes, we setup Mailgun for transactional email, because this helps web based forms, and other, email to get sent to the right place. Its also free, as in beer, at least for the first 10,000 mails a months.

But we ran into a deliverability issue on one or two domains, which would sometime say things like:

550 Sender has no A, AAAA, or MX DNS records.

How to fix that? We thought. Well, the clue is in the message!

At the recipient, sometimes (though there is no actual standard or rule which says this should be done!), there is a DNS check to see if the sending domain is at the same URL as the domain from which the mail originated. Correctly formed SPF records should be respected and allow this, but there it is, some “spam filters” make this check.

But at Mailgun, we setup a special `mg.somedomain.com` subdomain to send transactional email from, right?

Yes, and that is where this “issue” stems from.

The fix?

Make a domain a record in your DNS which points to the same IP as the address from which your mailgun mail will originate from (often this will be where your “www” record will point), and, when this is updated and has propagated (yawn, we know, it takes a long time… can’t be helped) your mail will start sending correctly!

The record should be for the exact domain as your sending domain you setup in Mailgun – for example, if you’re sending from mg.somedomain.com and your server IP is 111.111.111.111 the record would look like:

A mg 111.111.111.111

If you use CloudFlare or another DNS proxy, it’s a little simpler if you turn off their DNS proxy feature, as this will reveal the “same” IP address as that from which your transactional mail will originate, which is partially what the spam filter you tripped up is checking for (whether or not this is a “correct” sending IP for THIS domain).

4 thoughts on “Fix Mailgun “550 Sender has no A, AAAA, or MX DNS records.””

Matt Panton

Hi, I’m running into the same error message that you were and I’ve tried fixing it but I’m not sure whether I’ve created the correct a-record. I added a mg.mydomain.co record with a value of the IP Address that is shown on my MailGun dashboard under Domians>mg.mydomain.co>Domain Information>IP Address. Is this correct or should it be the I.P Address of my main site? Thanks in advance �� Reply

Hi Matt, The A record should be setup at mg.mydomain.co to point to where your server is – the mail origin server. This is the IP where your website is hosted. So where your WWW a record points – to that IP. Or, if you have an @ a record, to that IP. Robin Reply

Very helpful article, thanks Robin! Reply

I actually did everything in this article, including setting A record for mg.mydomain.com in DNS records, but I am still getting the “550 Sender has no A, AAAA, or MX DNS records” error? To configure MailGun with GoDaddy, I have added/verified TXT records for my domain and added subdomain A record to DNS per this article (no MailGun MX records added to avoid existing MX record conflicts).. but I still can’t get GoDaddy emails to send after 48hours. Only Google emails send properly. Not sure what to do next? Reply

Leave a comment Cancel reply

About Silicon Dales

Silicon Dales are accredited WooCommerce developers and WordPress experts working remotely from an HQ in Manchester, UK.

Registered Office: Silicon Dales Ltd, Bloc, 17 Marble Street, Manchester, M2 3AW.

Contact Us

  • Tel: +44 (0)161 870 2536
  • Email: Getintouch@silicondales.com

Registered in England & Wales. Company number: 7324510. Directors: Robin J.E. Scott, Jonathan M.G. Farrington and Linda Scott. VAT Number GB 111 682 442.

Quick Links

Services

We offer a range of services, in the following general categories.

  • WordPress Development
  • WooCommerce Agency
  • Google Workspace
  • Marketing Automation
  • Content Production

MX or A record issues

We have a mail server (Mailenable) which we are using to sell email accounts to our clients. We have one client that could not send email to a specific domain and they receieve this error from the domain’s email server:

Reason: The message could not be delivered because the domain name ourclientcompanyname.com does not have any DNS records.

The company that uses us for email does not have any DNS records for their domain ourclientcompanyname.com MX records are fine but the domain has no other DNS records. Is that a possible error? What DNS records should the client should add?

  • domain-name-system
  • mx-record

32.7k 9 9 gold badges 82 82 silver badges 117 117 bronze badges
asked Feb 27, 2015 at 18:45
user776720 user776720
197 3 3 silver badges 12 12 bronze badges
Please tell us the domain in question.
Feb 27, 2015 at 18:47

I suspect they require an A or CNAME record. You appear to have MX records, but some ISPs may require an A/CNAME.

Feb 27, 2015 at 18:53
After adding an «A record» under domain the error has been solved!
Apr 6, 2015 at 6:57

3 Answers 3

MX records are fin but the domain has no dns record at all. Is that a possible error? What dns record the client should add?

Yes, some mail servers, upon receipt of an email, check to see that the domain for the sending user, not just the sending server, has DNS records. I think it’s a bit silly, and not a great check for spam, but it is what it is. Your client most likely needs to simply put an A record in for their ourclientcompanyname.com apex domain. Get them a $5 hosting account and a single page informational website for good measure, just to be nice.

EDIT:

Buried within ye olden RFC 5321, it says in section 2.3.5:

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP.

Noice! I still think it’s a silly to think of it as a spam deterrent and is a correlation/causation conflation, but hey at least it’s a documented standard and following it has some positive side effects on the spam folder! Who has two thumbs and just got RFC schooled?

enter image description here

answered Feb 27, 2015 at 18:56
32.7k 9 9 gold badges 82 82 silver badges 117 117 bronze badges
Actualy it’s not silly at all, and it blocks well over half the spam I would otherwise receive.
Feb 27, 2015 at 19:05

Is there an RFC or otherwise a standard that makes this a requirement? I’m curious about my assumptions. I mean, I’m sure it does block a lot of spam, but it’s still illogical and silly. Blocking one service based on another virtually unrelated service’s or host’s unavailability, regardless of outcome, is broken. There’s no actual need to have an A record at the apex of a sending domain for mail to be receieved. There are better standards-based ways of blocking spam. It’s just a silly hack that certainly works, but is still a hack. unless I’m standards deficient, which is very likely. =)

Feb 27, 2015 at 19:40

It’s not the zone apex, per se. It’s the name of the mail server, whatever it is. In this case, it just happens that they named the mail server the same as the naked domain name. If someone tells me EHLO spambox.spammer.com and spambox.spammer.com doesn’t resolve, then I’m going to tell them to get lost. And yes, RFC 5321 requires this (sect. 2.3.5)

Feb 27, 2015 at 19:48
Kittehs don’t got thumbs!
Mar 2, 2015 at 4:30

RFC 5321 section 2.3.5 requires that domain names used in email be resolvable to addresses.

From the relevant parts:

Only resolvable, fully-qualified domain names (FQDNs) are permitted when domain names are used in SMTP. In other words, names that can be resolved to MX RRs or address (i.e., A or AAAA) RRs (as discussed in Section 5) are permitted, as are CNAME RRs whose targets can be resolved, in turn, to MX or address RRs. Local nicknames or unqualified names MUST NOT be used. There are two exceptions to the rule requiring FQDNs:

  • The domain name given in the EHLO command MUST be either a primary host name (a domain name that resolves to an address RR) or, if the host has no name, an address literal, as described in Section 4.1.3 and discussed further in the EHLO discussion of Section 4.1.4.

This is not a new requirement; RFC 2821 section 2.3.5 (2001) had similar language.

The domain name, as described in this document and in [22], is the entire, fully-qualified name (often referred to as an «FQDN»). A domain name that is not in FQDN form is no more than a local alias. Local aliases MUST NOT appear in any SMTP transaction.

If your mail server says EHLO company.example and company.example can’t be resolved to an address, then it’s perfectly valid to reject that connection. The same is true of the domain names used in the sender and recipient addresses (with the exception of postmaster, which doesn’t require a domain name at all).

(Prior to RFC 2821, the governing standards were RFC 821 and RFC 974, which date to the 1980s and had to accommodate many non-Internet networks which no longer exist, thus the standards were much less restrictive.)

Почтовый сервер не передаются сообщения на некоторые доменами

Доброго времени суток. Настроил postfix. Почта ходит внутри домена domain.ua, а также на rambler.ru yandex.ua gmail.com gcn.ua. Но вот проблемы с mail.ru и urk.net.

При отправки с них на domain.ua получаю следующую ошибку

ivan@domain.ua all relevant MX records point to non-existent hosts or (invalidly) to IP addresses

При отправке с domain.ua на mail.ru

host mxs.mail.ru[94.100.176.20] said: 503 Valid RCPT command must precede DATA (in reply to end of DATA command)
soft_bounce = no queue_directory = /var/spool/postfix daemon_directory = /usr/libexec/postfix mail_owner = postfix default_privs = nobody myhostname = mail.domain.ua mydomain = domain.ua myorigin = $mydomain mydestination = $myhostname,localhost.$myhostname,localhost local_recipient_maps = $virtual_mailbox_maps, $virtual_alias_maps, $transport_maps unknown_local_recipient_reject_code = 550 mynetworks = 127.0.0.0/8 ip/24 relay_domains = $transport_maps alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases.db mail_spool_directory = /var/mail smtpd_banner = $myhostname ESMTP debug_peer_level = 2 debug_peer_list = 127.0.0.1 debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 sendmail_path = /usr/sbin/sendmail mailq_path = /usr/bin/mailq setgid_group = postdrop html_directory = no manpage_directory = /usr/local/man config_directory = /etc/postfix virtual_mailbox_domains = mysql:$config_directory/sql/vdomains.cf virtual_mailbox_base = /var/vmail virtual_mailbox_maps = mysql:$config_directory/sql/vmailbox.cf virtual_alias_maps = mysql:$config_directory/sql/valias.cf virtual_minimum_uid = 1150 virtual_uid_maps = static:1150 virtual_gid_maps = static:12 virtual_transport = dovecot dovecot_destination_recipient_limit = 1 smtpd_sasl_exceptions_networks = $mynetworks broken_sasl_auth_clients = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_sasl_type = dovecot smtpd_sasl_path = /var/spool/postfix/dovecot-auth content_filter = scan:127.0.0.1:10025 #receive_override_options = no_address_mappings smtpd_client_restrictions = permit_mynetworks, permit_sasl_authenticated, permit smtpd_helo_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_invalid_helo_hostname, reject_non_fqdn_helo_hostname, reject_unknown_helo_hostname, permit smtpd_sender_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_non_fqdn_sender, reject_unknown_sender_domain, permit smtpd_recipient_restrictions = reject_non_fqdn_recipient, reject_unknown_recipient_domain, permit_sasl_authenticated, reject_unlisted_recipient, permit_mynetworks, reject_unauth_destination, permit smtpd_data_restrictions = permit_mynetworks, reject_unauth_pipelining, reject_multi_recipient_bounce, permit smtpd_etrn_restrictions = reject smtpd_helo_required = yes smtpd_discard_ehlo_keywords = etrn, silent-discard smtpd_forbidden_commands = CONNECT GET POST disable_vrfy_command = yes smtp_use_tls = yes smtpd_use_tls = yes smtpd_tls_auth_only = yes smtp_tls_note_starttls_offer = yes smtpd_tls_cert_file = /etc/postfix/certs/smtpd.pem smtpd_tls_key_file = /etc/postfix/certs/smtpd.pem smtpd_tls_CAfile = /etc/postfix/certs/smtpd.pem smtpd_tls_received_header = yes smtpd_tls_loglevel = 2 

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *