n	1	Error 503 (Server Error)!!1	n	1	Skip to main content
	2			2
n	3	**503.** That’s an error.	n	3	Google Workspace Admin Help
	4			4
n	5	The service you requested is not available yet.	n	5	Sign in
	6			6
n	7	Please try again in 30 seconds. That’s all we know.	n	7	Google Help
	8			8
n			n	9	* Help Center
				10	* Community
				11	* Google Workspace Admin
	9			12
t			t	13	* Privacy Policy
				14	* Terms of Service
				15	* Submit feedback
				16
				17	Send feedback on...
				18
				19	This help content & information
				20
				21	General Help Center experience
				22
				23	Next
				24
				25	* Help Center
				26	* Community
				27	*
				28
				29	Google Workspace Admin
				30
				31	* Contact support / fix a problem
				32	* Fix a problem
				33	* Gmail issues
				34	* Problems with sending
				35	* Email sender guidelines
				36
				37	# Email sender guidelines
				38
				39	The guidelines in this article can help you successfully send and
				>	deliver
				40	email to personal Gmail accounts. Starting in 2024, email senders
				>	must meet
				41	the requirements described here to send email to Gmail personal a
				>	ccounts. A
				42	personal Gmail account is an account that ends in @gmail.com or
				43	@googlemail.com.
				44
				45	For the latest updates about sender requirements, visit the Email
				>	sender
				46	guidelines FAQ.
				47
				48	**Google Workspace senders:** If you use Google Workspace to send
				>	large
				49	volumes of email, review the Spam and abuse policy in Gmail. The
				>	policy is
				50	part of the Google Workspace Acceptable Use Policy.
				51
				52	## Sender requirements updates
				53
				54	This table lists our updates to the sender guidelines and require
				>	ments:
				55
				56	Sender requirement | Date added
				57	---|---
				58	Use a TLS connection for transmitting email | Dec. 2023
				59
				60	## Sender requirements and guidelines
				61
				62	Follow these guidelines to help ensure messages are delivered to
				>	Gmail
				63	accounts as expected, and to help prevent Gmail from limiting sen
				>	ding rates,
				64	blocking messages, or marking messages as spam.
				65
				66	Requirements for all senders
				67
				68	Starting February 1, 2024, all email senders who send email to Gm
				>	ail accounts
				69	must meet the requirements in this section.
				70
				71	**Important:** If you send more than 5,000 messages per day to Gm
				>	ail accounts,
				72	follow the Requirements for sending 5,000 or more messages per da
				>	y.
				73
				74	* Set up SPF or DKIM email authentication for your sending doma
				>	ins.
				75	* Ensure that sending domains or IPs have valid forward and rev
				>	erse DNS records, also referred to as PTR records. Learn more
				76	* Use a TLS connection for transmitting email. For steps to set
				>	up TLS in Google Workspace, visit Require a secure connection fo
				>	r email.
				77	* Keep spam rates reported in Postmaster Tools below 0.3%. Lear
				>	n more about spam rates
				78	* Format messages according to the Internet Message Format stan
				>	dard, RFC 5322.
				79	* Don’t impersonate Gmail From: headers. Gmail will begin using
				>	a DMARC quarantine enforcement policy, and impersonating Gmail F
				>	rom: headers might impact your email delivery.
				80	* If you manage a forwarding service, including mailing lists o
				>	r inbound gateways, add ARC headers to outgoing email. ARC header
				>	s indicate the message was forwarded and identify you as the forw
				>	arder. Mailing list senders should also add a List-id: header, wh
				>	ich specifies the mailing list, to outgoing messages.
				81
				82	Requirements for sending 5,000 or more messages per day
				83
				84	Starting February 1, 2024, email senders who send more than 5,000
				>	messages per
				85	day to Gmail accounts must meet the requirements in this section.
				86
				87	* Set up SPF and DKIM email authentication for your domain.
				88	* Set up DMARC email authentication for your sending domain. Yo
				>	ur DMARC enforcement policy can be set to none. Learn more
				89	* Ensure that sending domains or IPs have valid forward and rev
				>	erse DNS records, also referred to as PTR records. Learn more
				90	* Use a TLS connection for transmitting email. For steps to set
				>	up TLS in Google Workspace, visit Require a secure connection fo
				>	r email.
				91	* Keep spam rates reported in Postmaster Tools below 0.30%. Lea
				>	rn more about spam rates
				92	* Format messages according to the Internet Message Format stan
				>	dard, RFC 5322.
				93	* Don’t impersonate Gmail From: headers. Gmail will begin using
				>	a DMARC quarantine enforcement policy, and impersonating Gmail F
				>	rom: headers might impact your email delivery.
				94	* If you manage a forwarding service, including mailing lists o
				>	r inbound gateways, add ARC headers to outgoing email. ARC header
				>	s indicate the message was forwarded and identify you as the forw
				>	arder. Mailing list senders should also add a List-id: header, wh
				>	ich specifies the mailing list, to outgoing messages.
				95	* For direct email, the domain in the sender's From: header mus
				>	t be aligned with either the SPF domain or the DKIM domain. This
				>	is required to pass DMARC alignment.
				96	* Marketing messages and subscribed messages must support one-c
				>	lick unsubscribe, and include a clearly visible unsubscribe link
				>	in the message body. Learn more
				97
				98	If you send more than 5,000 emails per day before February 1, 202
				>	4, follow the
				99	guidelines in this article as soon as possible. Meeting the sende
				>	r
				100	requirements before the deadline may improve your email delivery.
				>	If you don’t
				101	meet the requirements described in this article, your email might
				>	not be
				102	delivered as expected, or might be marked as spam. To get help wi
				>	th email
				103	delivery issues, go to Troubleshooting.
				104
				105	### Email authentication requirements & guidelines
				106
				107	We require that you set up these email authentication methods for
				>	your domain:
				108
				109	* All senders: SPF or DKIM
				110	* Bulk senders: SPF, DKIM, and DMARC
				111
				112	Authenticated messages:
				113
				114	* Help protect recipients from malicious messages, such as spoo
				>	fing and phishing messages.
				115	* Help protect you and your organization from being impersonate
				>	d.
				116	* Are less likely to be rejected or marked as spam by Gmail.
				117
				118	Set up email authentication for each of your sending domains at y
				>	our domain
				119	provider. You can use instructions Google provides and our domain
				>	provider's
				120	email authentication support information.
				121
				122	To verify messages are authenticated, Google performs checks on m
				>	essages sent
				123	to Gmail accounts. To improve email delivery, we recommend that y
				>	ou always set
				124	up SPF, DKIM, and DMARC for your domains. Make sure you're meetin
				>	g the minimum
				125	authentication requirements described on this page. Messages that
				>	aren’t
				126	authenticated with these methods might be marked as spam or rejec
				>	ted with a
				127	5.7.26 error.
				128
				129	If you use an email service provider, verify that they authentica
				>	te your
				130	domain’s email with SPF and DKIM.
				131
				132	If you regularly forward email or manage a forwarding service, he
				>	lp ensure
				133	forwarded messages are authenticated by following our Best practi
				>	ces for
				134	forwarding email to Gmail.
				135
				136	We recommend you always set up email authentication for the domai
				>	n that hosts
				137	your public website
				138
				139	#### SPF
				140
				141	SPF prevents spammers from sending unauthorized messages that app
				>	ear to be
				142	from your domain. Set up SPF by publishing an SPF record at your
				>	domain. The
				143	SPF record for your domain should include all email senders for y
				>	our domain.
				144	If your third-party senders aren't included in your SPF record, m
				>	essages from
				145	these senders are more likely to be marked as spam. Learn how to
				>	define your
				146	SPF record and add it to your domain.
				147
				148	#### DKIM
				149
				150	Turn on DKIM for the domain that sends your email. Receiving serv
				>	ers use DKIM
				151	to verify that the domain owner actually sent the message. If you
				>	use Google
				152	Workspace to send email, learn how to turn on DKIM for your domai
				>	n. If you
				153	don’t use Google Workspace to send email, you can use one of many
				>	available
				154	internet tools to create your DKIM keys, or check with your domai
				>	n provider
				155	for help.
				156
				157	**Important:** Sending to personal Gmail accounts requires a DKIM
				>	key of 1024
				158	bits or longer. For security reasons, we recommend using a 2048-b
				>	it key if
				159	your domain provider supports this. Learn more about DKIM key len
				>	gth.
				160
				161	#### DMARC
				162
				163	DMARC tells receiving servers what to do with your messages that
				>	don’t pass
				164	SPF or DKIM. Set up DMARC by publishing a DMARC record for your d
				>	omain. To
				165	pass DMARC authentication, messages must be authenticated by SPF
				>	or DKIM, or
				166	both. The authenticating domain must be the same domain that appe
				>	ars in the
				167	message From: header. Learn how to set up DMARC.
				168
				169	We recommend you set up DMARC reports so you can monitor email se
				>	nt from your
				170	domain, or appears to have been sent from your domain. DMARC repo
				>	rts help you
				171	identify senders that may be impersonating your domain. Learn mor
				>	e about DMARC
				172	reports.
				173
				174	#### ARC
				175
				176	ARC checks the previous authentication status of forwarded messag
				>	es. If a
				177	forwarded message passes SPF or DKIM authentication, but ARC show
				>	s it
				178	previously failed authentication, Gmail treats the message as una
				>	uthenticated.
				179
				180	We recommend that senders use ARC authentication, especially if t
				>	hey regularly
				181	forward email. Learn more about ARC authentication.
				182
				183	### Infrastructure configuration requirements and guidelines
				184
				185	#### IP addresses
				186
				187	**Important:** The sending IP address must match the IP address o
				>	f the
				188	hostname specified in the Pointer (PTR) record.
				189
				190	The public IP address of a sending SMTP server must have a corres
				>	ponding PTR
				191	record that resolves to a hostname. This is called a _reverse DNS
				>	lookup_. The
				192	same hostname must also have an A (for IPv4) or AAAA (for IPv6) r
				>	ecord that
				193	resolves to the same public IP address used by the sending server
				>	. This is
				194	called a _forward DNS lookup_.
				195
				196	Set up valid reverse DNS records of your sending server IP addres
				>	ses that
				197	point to your domain. Check for a PTR record with the Google Admi
				>	n Toolbox Dig
				198	tool.
				199
				200	**Important:** The sending IP address must match the IP address o
				>	f the
				201	hostname specified in the Pointer (PTR) record.
				202
				203	#### Shared IP addresses
				204
				205	A shared IP address is an IP address used by more than one email
				>	sender. The
				206	activity of any senders using a shared IP address affects the rep
				>	utation of
				207	all senders for that shared IP address. A negative reputation can
				>	impact your
				208	delivery rate.
				209
				210	If you use a shared IP address for sending email:
				211
				212	* Make sure the shared IP address isn’t on any internet blockli
				>	st. Messages sent from IP addresses on a blocklist are more likel
				>	y to be marked as spam.
				213	* If you use an email service provider for your shared IP,  use
				>	Postmaster Tools to check the reputation of the shared IP addres
				>	s.
				214
				215	### Subscription requirements and guidelines
				216
				217	If you manage mailing lists or other email subscriptions, you sho
				>	uld send
				218	email only to people who want to get messages from you. These rec
				>	ipients are
				219	less likely to report your messages as spam. If messages from you
				>	r domain are
				220	frequently reported as spam, future messages from you are more li
				>	kely to be
				221	marked as spam. Over time, user spam reports can lower your domai
				>	n’s
				222	reputation. Check your spam rate and your domain and IP address r
				>	eputation
				223	with Postmaster Tools.
				224
				225	#### Make it easy to subscribe
				226
				227	To help ensure recipients are engaged:
				228
				229	* Make sure recipients opt in to get messages from you.
				230	* Confirm each recipient's email address before subscribing the
				>	m.
				231	* Periodically send messages to confirm that recipients want to
				>	stay subscribed.
				232	* Consider unsubscribing recipients who don’t open or read your
				>	messages.
				233
				234	#### Make it easy to unsubscribe
				235
				236	Always give recipients an easy way to unsubscribe from your messa
				>	ges. Letting
				237	people opt out of your messages can improve open rates, click-thr
				>	ough rates,
				238	and sending efficiency.
				239
				240	**Important:** If you send more than 5,000 message per day, your
				>	marketing and
				241	subscribed messages must support one-click unsubscribe.
				242
				243	To set up one-click unsubscribe for Gmail messages, include both
				>	of these
				244	headers in outgoing messages:
				245
				246	* List-Unsubscribe-Post: List-Unsubscribe=One-Click
				247
				248	* List-Unsubscribe: <https://solarmora.com/unsubscribe/example>
				249
				250	When a recipient unsubscribes using one-click, you receive this P
				>	OST request:
				251
				252	"POST /unsubscribe/example HTTP/1.1
				253	Host: solarmora.com
				254	Content-Type: application/x-www-form-urlencoded
				255	Content-Length: 26
				256	List-Unsubscribe=One-Click"
				257
				258	Learn more about List-Unsubscribe: headers in RFC 2369 and RFC 80
				>	58.
				259
				260	These unsubscribe options can also be used but they should not re
				>	place one-
				261	click unsubscribe:
				262
				263	* Let recipients review the individual mailing lists they’re su
				>	bscribed to. Let them unsubscribe from lists individually, or all
				>	lists at once.
				264	* Automatically unsubscribe recipients who have multiple bounce
				>	d messages.
				265
				266	### Message formatting requirements and guidelines
				267
				268	Follow these message formatting guidelines to help ensure message
				>	s are
				269	delivered as expected:
				270
				271	* If your messages are in HTML, format them according to HTML s
				>	tandards.
				272	* Follow these message header guidelines:
				273	* From: headers should include only one email address. For ex
				>	ample:
				274	From: notifications@solarmora.com
				275
				276	* Avoid excessively large message headers. To learn more, vis
				>	it Gmail message header limits.
				277	* Format messages according to the Internet Format Standard (RF
				>	C 5322).
				278	* Make sure every message includes a valid Message-ID.
				279	* Make sure single-instance message headers are included only
				>	once in a message. Examples of single-instance headers include F
				>	rom:, To:, Subject:, and Date:.
				280	* Message headers and message content should be accurate, and n
				>	ot misleading or deceptive.
				281	* Email message subject, headers, display names, and other me
				>	ssage elements should accurately represent the sender identity an
				>	d message content, and shouldn’t be misleading. For example, don’
				>	t send messages with subject lines starting with Re: or Fwd: unle
				>	ss the messages are actual replies or forwards, and include only
				>	actual senders and recipients in From: and To: headers.
				282	* Don't use emojis or other non-standard characters to imitat
				>	e graphic elements in messages, with the intent to deceive or inf
				>	luence recipients. For example, don’t use emojis or images next t
				>	o display names or brand names to imply the name has been verifie
				>	d in some way.
				283	* Don’t use HTML and CSS to hide content in your messages. Hi
				>	ding content might cause messages to be marked as spam.
				284	* Web links in the message body should be visible and easy to
				>	understand. Recipients should know what to expect when they clic
				>	k a link.
				285	* Sender information should be clear and visible.
				286	*   * Format the following international domains according to S
				>	ection 5.2 of Unicode Technical Standard #39. An international do
				>	main is also called an  _internationalized domain name (IDN_ ), a
				>	nd is a URL that is specific to a region or country.
				287	* Authenticating domain
				288	* Envelope from domain
				289	* Payload domain
				290	* Reply-to domain
				291	* Sender domain
				292
				293	### Sending practices requirements and guidelines
				294
				295	To reduce the chances that messages from your domain are sent to
				>	spam or
				296	blocked by Gmail, follow the best practices in this section.
				297
				298	* Authenticate email with SPF and DKIM that are aligned with ea
				>	ch other at the organizational level. If you use an email provide
				>	r, verify that your provider supports this.
				299	* Ideally, send all messages from the same IP address. If you m
				>	ust send from multiple IP addresses, use a different IP address f
				>	or each message type. For example, use one IP address for sending
				>	account notifications and a different IP address for sending pro
				>	motional messages.
				300	* Messages of the same category should have the same From: emai
				>	l address. For example, messages from a domain called **example.c
				>	om** might have From: addresses like:
				301
				302	* Sales receipt messages: **sales@example.com**
				303	* Promotional messages: **deals@example.com**
				304	* Account notification messages: **alert@example.com**
				305	* Messages sent from an address in the recipient’s contacts are
				>	less likely to be marked as spam.
				306
				307	#### Sending practices to avoid
				308
				309	* Don't mix different types of content in the same message. For
				>	example, don't include promotions in sales receipt messages.
				310	* Don't impersonate other domains or senders without permission
				>	. This practice is called _spoofing_ , and Gmail might mark these
				>	messages as spam.
				311	* Don't mark internal messages as spam. This can negatively aff
				>	ect your domain's reputation, and future messages might be marked
				>	as spam.
				312	* Don't purchase email addresses from other companies.
				313	* Don't send messages to people who didn't sign up to get messa
				>	ges from you. These recipients might mark your messages as spam,
				>	and future messages to these recipients will be marked as spam.
				314	* Avoid opt-in forms that are checked by default and that autom
				>	atically subscribe users. Some countries and regions restrict aut
				>	omatic opt-in. Before you opt-in users automatically, check the r
				>	egulations in your region.
				315
				316	Some legitimate messages may be marked as spam. Recipients can ma
				>	rk valid
				317	messages as not spam, so future messages from the sender should b
				>	e delivered
				318	to their inbox.
				319
				320	#### Increase sending volume slowly
				321
				322	When increasing sending volume, keep in mind:
				323
				324	* Increasing the sending volume too quickly can result in deliv
				>	ery problems. As you gradually increase your sending email volume
				>	, use Postmaster Tools to monitor email delivery.
				325	* For Google Workspace work and school accounts, sending limits
				>	apply even when recipients are in different Google Workspace dom
				>	ains. For example, you might send email to users with email addre
				>	sses that have the domains **your-company.net** and **example.com
				>	** _.  _Although the domains are different, if both domains have
				>	**google.com** as their MX record, messages sent to these domains
				>	count toward your limit.
				326	* If you use Google Workspace or Gmail for sending: When you re
				>	ach the sending limit, the sending rate is limited for the sendin
				>	g IP address.
				327
				328	If you send large amounts of email, we recommend you:
				329
				330	* Send email at a consistent rate. Avoid sending email in burst
				>	s.
				331	* Start with a low sending volume to engaged users, and slowly
				>	increase the volume over time.
				332	* As you increase the sending volume, regularly monitor server
				>	responses, spam rate, and the sending domain's reputation. Regula
				>	r monitoring will allow you to quickly adapt if your sending is r
				>	ate limited, if the spam rate is increased, or when the sending d
				>	omain's reputation drops.
				333	* Avoid introducing sudden volume spikes if you do not have a h
				>	istory of sending large volumes. For example, immediately doublin
				>	g previously sent volumes suddenly could result in rate limiting
				>	or reputation drops.
				334	* If you change the format of your bulk emails, gradually incre
				>	ase the sending volume of messages with the new format.
				335	* After making any significant changes to your sending infrastr
				>	ucture or email header structure, increase the modified segment o
				>	f traffic separately.
				336	* If messages start bouncing or start being deferred, reduce th
				>	e sending volume until the SMTP error rate decreases. Then, incre
				>	ase slowly again. If bounces and deferrals continue at a low volu
				>	me, review individual messages to identify problems. For example,
				>	you can try sending a blank test message and see if it experienc
				>	es issues.
				337	* Stay within the IP limits for sending:
				338	* Be aware of email sending limits when sending from domains
				>	that have a Google.com MX host.
				339	* Limit sending email from a single IP address based on the M
				>	X record domain, not the domain in the recipient email address.
				340	* Monitor responses so you can change sending rates as needed
				>	to stay within these limits.
				341
				342	These factors affect how quickly you can increase sending volume:
				343
				344	* Amount of email sent: The more email that you send, the more
				>	slowly you should increase sending volume.
				345	* Frequency of sending email: You can increase the sending volu
				>	me more quickly when you send daily instead of weekly.
				346	* Recipient feedback about your messages: Make sure you send on
				>	ly to people who subscribe to your emails, and give recipients an
				>	option to unsubscribe.
				347
				348	In the event of a recent spike in email activity, we recommend fo
				>	llowing the
				349	requirements and guidelines on this page to resolve deliverabilit
				>	y issues
				350	automatically during following sends.
				351
				352	## Additional guidelines
				353
				354	### Guidelines for using email service providers
				355
				356	Google and Gmail don’t accept allowlist requests from email provi
				>	ders. We
				357	can't guarantee messages sent by email providers will pass Gmail’
				>	s spam
				358	filters.
				359
				360	If you use a third-party email provider to send email for your do
				>	main:
				361
				362	* Verify that the provider follows the guidelines on this page.
				>	Large providers, such as Google, AOL, and Yahoo, typically follo
				>	w these guidelines.
				363	* Make sure the SPF record for your domain includes all email s
				>	enders for your domain. If third-party senders aren't included in
				>	your SPF record, messages sent from these providers are more lik
				>	ely to be marked as spam. Learn how to set up your SPF record.
				364
				365	If you use a domain provider but you manage your own email, we re
				>	commend you:
				366
				367	* Review and follow the requirements and guidelines on this pag
				>	e.
				368	* Use Postmaster Tools to monitor information about messages se
				>	nt from your domain to Gmail accounts.
				369
				370	### Guidelines for email service providers
				371
				372	When clients use your service to send email, you’re responsible f
				>	or their
				373	sending practices. We recommend taking these steps to help manage
				>	your
				374	clients’ sending activity:
				375
				376	* Offer an email address for reporting email abuse, for example
				>	: **abuse@email-provider.com**.
				377	* Make sure your contact information in your WHOIS record and o
				>	n abuse.net is current.
				378	* Immediately remove any client who uses your service to send s
				>	pam.
				379
				380	### Affiliate marketing
				381
				382	Affiliate marketing programs offer rewards to companies or indivi
				>	duals that
				383	send visitors to your website. However, spammers can abuse these
				>	programs. If
				384	your brand is associated with marketing spam, other messages sent
				>	by you might
				385	be marked as spam.
				386
				387	We recommend you regularly monitor affiliates, and remove any aff
				>	iliates that
				388	send spam.
				389
				390	### Phishing exercises
				391
				392	Don’t send test phishing messages or test campaigns from your dom
				>	ain. Your
				393	domain’s reputation might be negatively affected, and your domain
				>	could be
				394	added to internet blocklists.
				395
				396	## Monitoring and troubleshooting
				397
				398	### Postmaster Tools
				399
				400	Use Postmaster Tools to get information about the email you send
				>	to Gmail
				401	users, for example:
				402
				403	* When recipients mark your messages as spam
				404	* Why messages might not be delivered as expected
				405	* If messages are authenticated
				406	* Your domain or IP reputation and the impact on message delive
				>	ry rates
				407
				408	#### Spam rate
				409
				410	* #### Regularly monitor your domain's spam rate in Postmaster
				>	Tools.
				411
				412	* Keep spam rates reported in Postmaster Tools below 0.10% and
				>	avoid ever reaching a spam rate of 0.30% or higher. Learn more
				413	* Maintaining a low spam rate helps senders be more resilient t
				>	o occasional spikes in user feedback.
				414	* Maintaining a high spam rate leads to increased spam classifi
				>	cation. It can take time for improvements in spam rate to reflect
				>	positively on spam classification.
				415
				416	#### Open rate
				417
				418	* Google doesn't track open rates.
				419	* Google can't verify the accuracy of open rates reported by th
				>	ird parties.
				420	* Low open rates aren't necessarily an accurate indicator of de
				>	liverability or spam classification issues.
				421
				422	### Troubleshooting email delivery
				423
				424	If messages aren't being delivered as expected:
				425
				426	* Check regularly that your domain isn’t listed as unsafe with
				>	Google Safe Browsing.
				427	* To check your domain status, enter your domain in the Safe Br
				>	owsing site status page.
				428	* Regularly check the status of any domains that are linked to
				>	yours.
				429
				430	#### Sending with email service providers
				431
				432	If you’re having delivery issues with email sent by a service pro
				>	vider, verify
				433	the provider follows the requirements and guidelines on this page
				>	.
				434
				435	#### Use the Google Admin Toolbox to review domain settings
				436
				437	Use the Google Admin Toolbox to check and fix settings for your d
				>	omain.
				438
				439	#### Fix the source of rejected email
				440
				441	If your messages are rejected, you might get an error message. Le
				>	arn more
				442	about the error so you can fix the problem. Common error messages
				>	are:
				443
				444	* **421, "4.7.0":** **** Messages are rejected because the send
				>	ing server’s IP address is not on the allowed list for the recipi
				>	ent’s domain.
				445	* **550, "5.7.1":** Messages are rejected because the sending s
				>	erver’s IP address is on an IP suspended list. You might get this
				>	error if you’re sending email using a shared IP with a poor repu
				>	tation.
				446
				447	Learn more about email and SMTP error messages:
				448
				449	* SMTP error reference
				450	* Fix bounced or rejected emails
				451
				452	#### Fix IPv6 authorization errors
				453
				454	An IPv6 authorization error could mean that the PTR record for th
				>	e sending
				455	server isn’t using IPv6. If you use an email service provider, co
				>	nfirm they’re
				456	using an IPv6 PTR record.
				457
				458	Here's an example of an IPv6 authorization error:
				459
				460	**550-5.7.1:** Message does not meet IPv6 sending guidelines rega
				>	rding PTR
				461	records and authentication.
				462
				463	#### Use the troubleshooting tool
				464
				465	If you’re still having email delivery problems after following th
				>	e guidelines
				466	in this article, try Troubleshooting for senders with email deliv
				>	ery issues.
				467
				468	## Related topics
				469
				470	* Email sender guidelines FAQ
				471	* Fixed bounced emails
				472	* Fix messages rejected by Google Groups
				473
				474	_Translations of our policies are provided for your convenience.
				>	If there is a
				475	conflict between the text of this policy in language other than E
				>	nglish and
				476	the text of the English language version of the policy, the text
				>	of the
				477	English language version of the policy takes precedence._
				478
				479	## Was this helpful?
				480
				481	How can we improve it?
				482
				483	YesNo
				484
				485	Submit
				486
				487	## Need more help?
				488
				489	### Try these next steps:
				490
				491	Post to the help community  Get answers from community members
				492
				493	Contact us Tell us more and we’ll help you get there
				494
				495	true
				496
				497	## Problems with sending
				498
				499	* 1 of 10
				500
				501	Fix bounced or rejected emails
				502
				503	* 2 of 10
				504
				505	Fix email bounces due to blocked IP address
				506
				507	* 3 of 10
				508
				509	Messages from a bulk sender bounce
				510
				511	* 4 of 10
				512
				513	Message bounced due to a policy rule
				514
				515	* 5 of 10
				516
				517	Email bounces with error message
				518
				519	* 6 of 10
				520
				521	Avoid issues when changing MX records
				522
				523	* 7 of 10
				524
				525	Best practices for forwarding email to Gmail
				526
				527	* 8 of 10
				528
				529	Some recipients don't get my email
				530
				531	* 9 of 10
				532
				533	SMTP relay spam policy in Gmail
				534
				535	* 10 of 10
				536
				537	Email sender guidelines
				538
				539	![](https://lh3.googleusercontent.com/exxMjxadqER4Ie3_TMeBqZfSwNB
				>	fL_3tU0Xvn4tJ3_POtw4haXNbIx7OL7v52_DcaBpe=w96)
				540
				541	Start your free 14-day trial today
				542
				543	Professional email, online storage, shared calendars, video meeti
				>	ngs and more.
				544	Start your free Google Workspace trial today.
				545
				546	* ©2024 Google
				547	* Privacy Policy
				548	* Terms of Service
				549
				550	Language  DeutschespañolfrançaisIndonesiaitalianoNederlandspolski
				>	português
				551	(Brasil)svenskaTiếng
				552	ViệtTürkçeрусскийукраїнськаעבריתالعربيةไทย中文（简体）中文（繁體）日本語한국어 Engl
				>	ish
				553
				554	Enable Dark Mode
				555
				556	Send feedback on...
				557
				558	This help content & information General Help Center experience
				559
				560	Search
				561
				562	Clear search
				563
				564	Close search
				565
				566	Google apps
				567
				568	Main menu
				569
				570
				571
				572	true
				573
				574	Search Help Center
				575
				576	true
				577
				578	true
				579
				580	true
				581
				582	true
				583
				584	true
				585
				586
				587
				588	false
				589
				590	false
				591
				592

Legends
Colors  Added  Changed Deleted	Links (f)irst change (n)ext change (t)op